On 2/22/07, Zeugswetter Andreas ADI SD <ZeugswetterA@spardat.at> wrote:
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.
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.
The actual storage used by the root tuple is now released (or we can
add another item pointer to keep track of it so that it can be reused
without vacuum of the page. But lets defer that for the time being).
In short, the pointer is NOT stored in the tuple header, but in the
item-id.
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.
I hope things would be more clear once I post next version of the
HOT-patch. But I really appreciate these comments.
Thanks,
Pavan
--
EnterpriseDB
http://www.enterprisedb.com
