On 2/22/07, Zeugswetter Andreas ADI SD <[EMAIL PROTECTED]> 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