"Pavan Deolasee" <[EMAIL PROTECTED]> 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
---(end of broadcast
On 9/13/07, Tom Lane <[EMAIL PROTECTED]> 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.
Gregory Stark <[EMAIL PROTECTED]> 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 s
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> 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 HO
"Tom Lane" <[EMAIL PROTECTED]> 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?
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