Re: HOT for PostgreSQL 8.3 - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: HOT for PostgreSQL 8.3
Date
Msg-id 2e78013d0702220524w6d2f6386k60aecee328a03154@mail.gmail.com
Whole thread Raw
In response to Re: HOT for PostgreSQL 8.3  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
Responses Re: HOT for PostgreSQL 8.3
List pgsql-hackers

On 2/22/07, Zeugswetter Andreas ADI SD <ZeugswetterA@spardat.at> wrote:
>
> Yes, thats one option. Though given a choice I would waste
> four bytes in the heap-page than inserting a new index entry.

No question about that. My point was, that it would mean wasting
the 2 (2 must be enough for a slot pointer) bytes on every heap tuple,
hot or not. And then the decision is not so obvious anymore.
If you don't have the room for the back pointer on every slot,
there is no room to add one later.


Oh yes, I agree. I was referring to the idea of line pointer redirection
which would waste four bytes (for the root line pointer)  per
hot-update chain. That occurs only when a tuple is hot-updated.
So there is no overhead for normal tuples. Also, since its outside
the tuple header, we don't have issues of additional space wastage
because of alignment.

We would need to teach the code to ignore all such pointers which
don't point to a real tuple, but only redirects us to another line pointer.
We arrive at this line pointer from the index and then get redirected
to another line pointer on the same page. Vacuum would need to
delay freeing this line pointer until the hot-update chain is dead.

I am waiting for feedback on this since I would like to work on
this next. Anybody sees any issue with this approach ? Comments
please.

Thanks,
Pavan

--

EnterpriseDB     http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: SCMS question
Next
From: Teodor Sigaev
Date:
Subject: Re: tsearch in core patch, for inclusion