Re: HOT for PostgreSQL 8.3

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Hannu Krosing" <hannu(at)skype(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, "Pavan Deolasee" <pavan(dot)deolasee(at)enterprisedb(dot)com>, "Nikhil S" <nikhil(dot)sontakke(at)enterprisedb(dot)com>
Subject: Re: HOT for PostgreSQL 8.3
Date: 2007-02-22 13:24:06
Message-ID: 2e78013d0702220524w6d2f6386k60aecee328a03154@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/22/07, Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2007-02-22 13:26:23 Re: tsearch in core patch, for inclusion
Previous Message Stefan Kaltenbrunner 2007-02-22 13:20:25 Re: SCMS question