Re: Remove xmin and cmin from frozen tuples

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Remove xmin and cmin from frozen tuples
Date: 2005-09-07 05:31:01
Message-ID: 20050907053101.GB60481@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 06, 2005 at 07:02:20PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> > If the 4 header fields in question were just normalized out, wouldn't
> > all the semantics continue to work the same? All I'm envisioning is
> > replacing them in each tuple with a pointer (vis_id) to another
> > datastore that would be roughly equivalent to:
>
> > CREATE TABLE visibility (
> > vis_id SERIAL,
> > xmin int,
> > xmax int,
> > cmin int,
> > cmax_xmax int
> > )
>
> > Of course you wouldn't use an actual table to do this, but hopefully
> > this clarifies my idea.
>
> Let's see ... replace every tuple access with TWO tuple accesses
> ... yes, that should improve performance nicely. And no, I'm not
> sure the semantics are the same, particularly w.r.t. atomicity of
> state changes.

Well, like I said, I'm not envisioning using a table to store that info.
Since we'd be storing 4 fixed-length fields, you wouldn't need to
actually store vis_id per entry, just use the offset into the page.
Assuming you use one 'slot' to store the id of the first set, you could
store 511 tuples per page, which doesn't sound very bad.

But this is why I'm hoping a quick patch could be done so that this
could be tested.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2005-09-07 05:38:44 Re: [HACKERS] How to determine date / time of last postmaster restart
Previous Message nathan wagner 2005-09-07 05:15:08 Re: uuid type for postgres