| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
indenting. Also static variable indenting.
|
|
|
|
Fix very old bug which made tuples changed/inserted by a commnd
visible to command itself (so we had multiple update of updated tuples,
etc).
|
|
|
|
|
|
Reply-To: [email protected], Dan McGuirk <[email protected]>
To: [email protected]
Subject: [HACKERS] tmin writeback optimization
I was doing some profiling of the backend, and noticed that during a certain
benchmark I was running somewhere between 30% and 75% of the backend's CPU
time was being spent in calls to TransactionIdDidCommit() from
HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that
changed rows' transactions had in fact been committed even though the rows'
tmin values had not yet been set.
When a query looks at a given row, it needs to figure out whether the
transaction that changed the row has been committed and hence it should pay
attention to the row, or whether on the other hand the transaction is still
in progress or has been aborted and hence the row should be ignored. If
a tmin value is set, it is known definitively that the row's transaction
has been committed. However, if tmin is not set, the transaction
referred to in xmin must be looked up in pg_log, and this is what the
backend was spending a lot of time doing during my benchmark.
So, implementing a method suggested by Vadim, I created the following
patch that, the first time a query finds a committed row whose tmin value
is not set, sets it, and marks the buffer where the row is stored as
dirty. (It works for tmax, too.) This doesn't result in the boost in
real time performance I was hoping for, however it does decrease backend
CPU usage by up to two-thirds in certain situations, so it could be
rather beneficial in high-concurrency settings.
|
|
|
|
Change #include "" to #include <>
Remove a few unused #includes
Make sure it compiles with -Wall -Werror
|
|
|
|
Compiled with -Wall -Werror
|
|
|
|
I found another bug in btree index. Looking at the code it seems that NULL
keys are never used to build or scan a btree index (see the explain commands
in the example). However this is not the case when a null key is retrieved
in an outer loop of a join select and used in an index scan of an inner loop.
This bug causes at least three kinds of problems:
1) the backend crashes when it tries to compare a text string with a null.
2) it is not possible to find tuples with null keys in a join.
3) null is considered equal to 0 when the datum is passed by value, see
the last query.
Submitted by: Massimo Dal Zotto <[email protected]>
|
|
|
|
indextuple.c:159: warning: `bp' might be used uninitialized in this function
this directory passes -Wall -Werror under FreeBSD
|
|
Mainly...fix up the includes I removed, as well as prototypes
Pointed out by D'Arcy
|
|
access/common...how many more directories to go? :)
|
|
|
|
|
