Representation of redirected line pointers in HOT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Representation of redirected line pointers in HOT
Date: 2007-09-12 18:30:02
Message-ID: 25006.1189621802@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I find the HOT patch's representation of redirected line pointers pretty
klugy. It's got a magic offset number to mean one thing, and a magic
length number to mean something else, and the assumption that either of
these can't correspond to a real offset or length seems pretty weak.
(It would fail if we could have one-byte tuples, which of course is
nowhere near reality, but still...)

What I'm thinking is that we should instead do this by extending the use
of the lp_flags field. lp_flags is two bits, which we currently define
as independent LP_USED and LP_DELETE bits, but in fact LP_DELETE is
never used in heap pages. (It is used in indexes.) I propose that
we redefine lp_flags as having four states, say

LP_UNUSED 0
LP_NORMAL 1
LP_REDIRECT 2
LP_DEAD 3

The LP_DEAD state would have slightly different meanings in indexes and
heap pages: in an index this would represent an entry that is known dead
but hasn't been deleted, whereas in a heap page this would correspond to
what the HOT patch calls a "redirect dead" line pointer, that is one
that has no associated tuple storage but can't be removed because index
entries still link to it. We could make that difference explicit in the
line pointer, though: if it still has storage then lp_offset and lp_len
point to that storage, and if it doesn't have storage then they are set
to zero.

UNUSED pointers would also have offset = len = 0, and REDIRECT pointers
would have offset = link to next line pointer and len = 0, leading to
the general rule that "if it's got storage, len > 0, otherwise len = 0".

The above state values are chosen with malice aforethought to match the
bit patterns for the LP_USED/LP_DELETE combinations that are actually in
use today, so this change is upward compatible, except that I'm not sure
how careful we are about setting len = 0 in unused line pointers.

This seems hardly any uglier than the way the code stands today, and
certainly a lot less ugly than what the current HOT patch proposes.

Comments?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-09-12 18:40:46 Re: RETURNING and DO INSTEAD ... Intentional or not?
Previous Message Richard Huxton 2007-09-12 18:15:11 Re: RETURNING and DO INSTEAD ... Intentional or not?