> > > Yes, thats one option. Though given a choice I would waste four
> > > bytes in the heap-page than inserting a new index entry.
> >
> > No question about that. My point was, that it would mean wasting the
2
> > (2 must be enough for a slot pointer) bytes on every heap tuple, hot
> > or not. And then the decision is not so obvious anymore.
> > If you don't have the room for the back pointer on every slot, there
> > is no room to add one later.
> >
> >
> Oh yes, I agree. I was referring to the idea of line pointer
> redirection which would waste four bytes (for the root line
> pointer) per hot-update chain. That occurs only when a tuple
> is hot-updated.
> So there is no overhead for normal tuples.
I think you are still misunderstanding me, sorry if I am not beeing
clear
enough. When the row is hot-updated it is too late. You do not have room
in the root for the line pointer.
Say a table's tuple size is typically 40 bytes. Your root slot has room
for exactly 40 bytes. When the new tuple also (as expected) needs 40
bytes
there is no room for the line pointer.
Or are you suggesting, that vacuum resizes all root tuples to make room
for
the extra bytes, and only then you can use it ? Imho that would not be
good.
Imho the "relink root to newest dead tuple during update" path is more
promising, and does not depend on vacuum.
If we do reuse dead tuples without vacuum we should probably, as already
suggested,
disconnect the "what is dead enough for reuse/vacuum" from global xmin
right from the
start.
Andreas
