> I think the word "line pointer" is causing some confusion 
> here. Let me explain the idea again: Each page has a set of 
> line pointers OR item-ids as they are referred in the code (I 
> shall use the word item-id here after).
> The item-id stores the offset(15 bits), length (15 bits) and 
> two flags, LP_USED and LP_DELETE (2 bits).
> The root tuple is pointed to by some item-id (say, I1) on the 
> page. When the tuple is hot updated, a heap-only tuple is 
> added which is linked to the root tuple by its t_ctid and is 
> pointed by another item-id I2 on the page.
> Now, when the root tuple subsequently becomes DEAD, I am 
> proposing to store I2 in the offset field of I1. The length 
> field in I1 can be set to zero (or some other special value) 
> to mark that I1 is now just a redirection to I2 and does not 
> point to any real tuple, dead or live.

Oh, thanks for explaining. I was really misunderstanding.
Is that possible ? I thought item-id's (slots) need to be in physical

> 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.
> I did not get that completely. Can you elaborate on that ?
> Once we find a heap-only DEAD tuple, we remove it from the
> tuple-chain (and thus remove its only reference) and set LP_DELETE
> on its item-id. When we run out of free-space in a page, we search for
> an item-id whose LP_DELETE is set and whose length is atleast equal
> to the new tuple length. We reuse that item-id and the associated
> storage for storing the new tuple.

With the recent discussion about flashback (explicitly setting a
to 5 min ago) and forensics, I think we should have a way to delay
what is considered "DEAD and available for immediate reuse".
I know this can reduce the efficiency of HOT when delayed too far,
but I think we should have that possibility if we reuse without vacuum.


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to