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:

> 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]>

  + 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

Reply via email to