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.
Hm.. In that case, couldn't we prune the chain while we followed it, with
nearly zero overhead at all? It seems that we'd just have to always update
the root line pointer / tuples to point at the first RECENTLY_DEAD tuple in the
chain, together with maybe compacting the orphaned tuples to just a line pointer
I'm not sure how HOT handles this currently, but it seems that this sort of
minimal pruning shouldn't need WAL.
greetings, Florian Pflug
