> > > 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org