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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not
      match

Reply via email to