pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedRepresentation of redirected line pointers in HOT
6+ messages / 4 participants
[nested] [flat]
* Representation of redirected line pointers in HOT
@ 2007-09-12 18:30 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 6+ messages in thread
From: Tom Lane @ 2007-09-12 18:30 UTC (permalink / raw)
To: 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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Representation of redirected line pointers in HOT
@ 2007-09-12 22:29 Gregory Stark <stark@enterprisedb.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 6+ messages in thread
From: Gregory Stark @ 2007-09-12 22:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> LP_UNUSED 0
> LP_NORMAL 1
> LP_REDIRECT 2
> LP_DEAD 3
> 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?
If I understand correctly this still leaves open the possibility of
implementing in the future "quick pruning" as we've been speculating about. We
could represent that with a line pointer which is LP_DEAD but still has a
length and offset. I'm not sure we need to do it now but I'll be glad if we
aren't foreclosing the possibility.
These kinds of rethinks are typical of the tension between someone writing a
patch to submit for review, where they often want to keep the lines of code
changed to a minimum to avoid conflicts and to avoid giving reviewers extra
code to read which, and normal code maintenance.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Representation of redirected line pointers in HOT
@ 2007-09-12 22:42 Bruce Momjian <bruce@momjian.us>
parent: Gregory Stark <stark@enterprisedb.com>
1 sibling, 0 replies; 6+ messages in thread
From: Bruce Momjian @ 2007-09-12 22:42 UTC (permalink / raw)
To: Gregory Stark <stark@enterprisedb.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers
Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
> > LP_UNUSED 0
> > LP_NORMAL 1
> > LP_REDIRECT 2
> > LP_DEAD 3
>
> > 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?
>
> If I understand correctly this still leaves open the possibility of
> implementing in the future "quick pruning" as we've been speculating about. We
> could represent that with a line pointer which is LP_DEAD but still has a
> length and offset. I'm not sure we need to do it now but I'll be glad if we
> aren't foreclosing the possibility.
>
> These kinds of rethinks are typical of the tension between someone writing a
> patch to submit for review, where they often want to keep the lines of code
> changed to a minimum to avoid conflicts and to avoid giving reviewers extra
> code to read which, and normal code maintenance.
Yes, good point. This is why I am glad Tom can give it a full review.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Representation of redirected line pointers in HOT
@ 2007-09-12 22:46 Tom Lane <tgl@sss.pgh.pa.us>
parent: Gregory Stark <stark@enterprisedb.com>
1 sibling, 0 replies; 6+ messages in thread
From: Tom Lane @ 2007-09-12 22:46 UTC (permalink / raw)
To: Gregory Stark <stark@enterprisedb.com>; +Cc: pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> If I understand correctly this still leaves open the possibility of
> implementing in the future "quick pruning" as we've been speculating about. We
> could represent that with a line pointer which is LP_DEAD but still has a
> length and offset. I'm not sure we need to do it now but I'll be glad if we
> aren't foreclosing the possibility.
You could still do that, but I'm not sure I see the point.
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Representation of redirected line pointers in HOT
@ 2007-09-13 03:39 Pavan Deolasee <pavan.deolasee@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 6+ messages in thread
From: Pavan Deolasee @ 2007-09-13 03:39 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers
On 9/13/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>
> 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
>
>
Sounds good to me. I saw you committed this change. Do you want me
to update HOT patch to use this or you are already doing that ?
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: Representation of redirected line pointers in HOT
@ 2007-09-13 03:51 Tom Lane <tgl@sss.pgh.pa.us>
parent: Pavan Deolasee <pavan.deolasee@gmail.com>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2007-09-13 03:51 UTC (permalink / raw)
To: Pavan Deolasee <pavan.deolasee@gmail.com>; +Cc: pgsql-hackers
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> Sounds good to me. I saw you committed this change. Do you want me
> to update HOT patch to use this or you are already doing that ?
I'll clean up my own mess ;-)
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2007-09-13 03:51 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-09-12 18:30 Representation of redirected line pointers in HOT Tom Lane <tgl@sss.pgh.pa.us>
2007-09-12 22:29 ` Gregory Stark <stark@enterprisedb.com>
2007-09-12 22:42 ` Bruce Momjian <bruce@momjian.us>
2007-09-12 22:46 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-09-13 03:39 ` Pavan Deolasee <pavan.deolasee@gmail.com>
2007-09-13 03:51 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox