Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>> Florian Pflug wrote:
>>> Heikki Linnakangas wrote:
>>>> Tom Lane wrote:
>>>>> Compared to what it currently takes to check the same tuple (a separate
>>>>> index entry fetch and traversal to the heap page), this is already an
>>>>> enormous performance improvement.
>>>> Though keep in mind that we kill index tuples as soon as they're deemed
>>>> to be dead. Nevertheless, I'm not very worried about the cost of
>>>> following the chain either. But that's something we can quite easily
>>>> measure if we want to.
>>> I'm confused now. I though that pruning would be enough to shorten
>>> HOT-Chains -
>>> because the root line pointer afterwards points directly to the first live
>>> tuple. But we can *prune* (without actually defragmenting) without holding
>>> a VACUUM-strength lock, right? Or did I get that wrong?
>> Yes, that's right. You don't seem to be confused at all.
>>
>> Tom argued that following the tuple chain is cheap enough, and might
>> even be cheaper than what we have now, that we don't need to prune just
>> for the purpose of keeping the chains short. To which I pointed out that
>> currently, without HOT, we mark index tuples pointing to dead tuples as
>> killed to avoid following them in the future, so HOT without pruning is
>> not cheaper than what we have now.
>
> The central idea I now understand is that pruning only shrinks HOT
> chains. It does not allow reuse of space. Only defragmentation does
> that, and that is triggered when the page is almost full.
I was under the impression that pruning *does* free the space occupied
by DEAD HOT-Tuples (minus the size of a redirection line pointer). It
just doesn't defragment, so how much of that freed space you can actually
use to store new tuples is another question...
Or is that wrong - do we need a VACUUM-strength lock to turn a tuple
into a redirecting line pointer, and can pruning therefore only really
free *no* space?
greetings, Florian Pflug
