Re: HOT for PostgreSQL 8.3

> 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
order.

> 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
snapshot
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.

Andreas