Re: Remove xmin and cmin from frozen tuples - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: Remove xmin and cmin from frozen tuples
Date
Msg-id 20050907053101.GB60481@pervasive.com
Whole thread Raw
In response to Re: Remove xmin and cmin from frozen tuples  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Remove xmin and cmin from frozen tuples
List pgsql-hackers
On Tue, Sep 06, 2005 at 07:02:20PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.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@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: nathan wagner
Date:
Subject: Re: uuid type for postgres
Next
From: "Jim C. Nasby"
Date:
Subject: Re: [ADMIN] How to determine date / time of last postmaster restart