On 9/6/07, Gregory Stark <[EMAIL PROTECTED]> wrote: > > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > > > 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. > > Ah, as I understand it you can't actually do the pruning then because the > executor holds references to source tuple on the page. In other words you > can > never "get the vacuum lock" there because you already have the page pinned > yourself. > > I don't think executor holding a reference is a problem because when we check for vacuum lock, we have already pinned the page anyways. But moving the old tuple around deep down in the UPDATE code path (when we realize that there is no free space) is an issue. I know Heikki tried to do it this way - but then moved the pruning code to lookup code. Heikki ?
Another real problem with doing pruning only in UPDATE path is that we may end up with long HOT chains if the page does not receive a UPDATE, after many consecutive HOT updates. Every lookup to the visible tuple in this chain would be CPU expensive since it would require long chain following. The downside is of course that SELECT may occasionally do more work. But since we ensure that we do the extra work only when there is no contention on the page, ISTM that the downside is limited. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
