Simon Riggs <simon@2ndquadrant.com> writes:
> On Fri, 2007-09-07 at 22:08 -0400, Bruce Momjian wrote:
>> I don't see how following a HOT chain is any slower than following an
>> UPDATE chain like we do now.
> The speed/cost is the same. The issue is *when* we do this. Normal
> SELECTs will follow the chain each time we do an index lookup.
> So if our read/write ratio is 1000:1, then we will waste many cycles and
> yet the chain is never pruned on SELECT. So there really must be some
> point at which we prune on a SELECT.
This argument is too weak to stand up by itself.
Once a tuple is marked as committed dead (which it certainly must be
before you could even consider pruning it) the cost of skipping over
it in a HOT-chain search is going to be very very small. You have
already paid all the costs of searching the index, fetching and
pinning the heap page, etc. The incremental cost of rejecting one
more HOT-chain entry is the cost to
* fetch the line pointer;
* check HEAP_XMIN_COMMITTED and see that it's set;
* check xmin and see that it's valid per snapshot;
* check HEAP_XMAX_COMMITTED and see that it's set;
* check xmax and see that it's valid per snapshot;
* fetch t_ctid to chain to next tuple.
Now the snapshot checks could be relatively expensive --- but in any
situation where a tuple is potentially prunable, they'll reduce to *one*
comparison: is xid less than snapshot's xmin? So you've got two or at
most three shared-memory cache line fetches, no write to shared memory,
no locks taken or released, and a trivial number of CPU operations.
Compared to what it currently takes to check the same tuple (a separate
index entry fetch and traversal to the heap page), this is already an
enormous performance improvement. Insisting that we add complexity and
pay performance penalties elsewhere to reduce this cost still more does
not strike me as a sane tradeoff --- certainly not if it's being made
without conclusive performance measurements to back it up.
regards, tom lane