Simon Riggs <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly