Simon Riggs wrote: > > > If we defer pruning until the page is full, worst case we may could end > > > up with a chain ~240 tuples long, which might need to be scanned > > > repeatedly. That won't happen often, but it would be better to prune > > > whenever we hit one of these conditions > > > - when the block is full > > > - when we reach the 16th tuple in a chain > > Thanks for defining terms. > > Just to answer a few of your points: > > > 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.
But a sequential scan still follows the chain, and that isn't going to prune. Why are we more worried about index chain lookups than sequential scan lookups? As I understand it, the pruning is only to reduce the chains. It doesn't allow space reuse. I have updated my README to reflect that: ftp://momjian.us/pub/postgresql/mypatches/README.HOT > 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. > > Perhaps we could say if Xid % 16 == 0 then we prune, i.e. every 16th > transaction walking the chain will prune it. > > > Also, why all the talk of index lookups doing pruning? Can't a > > sequential scan do pruning? > > The SeqScan doesn't follow the chains, so can't easily determine whether > there are any long chains that need pruning. Its only when we come in > via an index that we need to walk the chain to the latest tuple version > and in that case we learn how long the chain is. Uh, as I understand it, every access follows the ctid, so why doesn't a sequential scan follow the chain? -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(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