On Wed, 2007-09-05 at 18:15 -0400, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
