On Wed, 2007-09-05 at 18:15 -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> Uh, why would any of this code at all execute during a pure lookup?
>
> > No idea. It seems an index lookup tries to prune a heap chain, and he
> > was asking if it should look at other chains on the page; I said not.
> > Whether the index lookup should prune the heap chain is another issue.
>
> ISTM the only time we should be doing HOT cleanup work is when we are
> trying to insert a new tuple on that page --- and maybe even only when
> we try and it doesn't fit straight off. Otherwise you're pushing
> maintenance work into foreground query pathways, which is exactly where
> I don't think we should be headed.
This is one of the many heuristics for tuning HOT.
We can choose to do this immediately, when the page fills or somewhere
in between.
The rationale was: In other circumstances we dirty a page to set a hint
bit on the first time we see the need for it. That avoids the clog
lookup on all later reads of that tuple. By analogy, we do the same
thing with HOT: when we see a tuple chain that can be pruned, we prune
it. If we dirty the page for the hint bit it seems like we may as well
dirty the page some more and prune it also at the same time.
We could begin pruning only when the chain is N long. Currently N=2, but
we could set N=3+ easily enough. There's no code yet to actually count
that, but we can do that easily as we do each lookup. We should also be
able to remember the visibility result for each tuple in the chain to
decide whether pruning will be effective or not.
I would say that if the buffer is already dirty and the chain is
prunable, we should prune it at the first possible chance.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
