Re: HOT patch - version 15

Pavan Deolasee wrote:
> On 9/6/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 ?

When I suggested that we get rid of the LP_DELETE flag for heap tuples,
the tuple-level fragmentation and all that, and just take the vacuum
lock and call PageRepairFragmentation, I was thinking that we'd do it in
heap_update and only when we run out of space on the page. But as Greg
said, it doesn't work because you're already holding a reference to at
least one tuple on the page, the one you're updating, by the time you
get to heap_update. That's why I put the pruning code to heap_fetch
instead. Yes, though the amortized cost is the same, it does push the
pruning work to the foreground query path.

That was a reason for separating the pruning and defragmenting a page.
We could do the pruning in heap_update, and only do the defragmenting in
heap_fetch. I was also thinking of an optimization to the pruning, so
that while we scan the page and remove dead tuples, we also check if we
leave behind an empty gap that's big enough to accommodate the new tuple
we're inserting, and reuse that space immediately, without defragmenting.

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

Yes. For that as well, we could prune only, but not defragment, the page
in the lookup path.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com