Re: HOT patch - version 15

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +