Re: Remove xmin and cmin from frozen tuples

On Wed, Sep 07, 2005 at 12:31:01AM -0500, Jim C. Nasby wrote:
> 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.

> 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.

I think this could be done with our "SLRU" mechanism, just like pg_clog,
pg_subtrans and pg_multixact do. Whether it's really a good idea or
not, it's another story. The problem is that you would be creating new
ones all the time, it would become a huge source of contention, and it
would use a lot of memory.

Anyway you are just moving the storage somewhere else -- instead of
having 4 fields in the tuple itself, you have one field which points
the same 4 fields elsewhere. I don't see how is that a win; it's
actually worse because you have to do two lookups. (And actually you
have just enlarged the storage requirements because you need to store
the "vis_id" twice.)

--
Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com
"La realidad se compone de muchos sueños, todos ellos diferentes,
pero en cierto aspecto, parecidos..." (Yo, hablando de sueños eróticos)