Re: Remove xmin and cmin from frozen tuples

On Tue, Sep 06, 2005 at 06:02:27PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> >>> If we're going to look at doing that I think it would also be good to
> >>> consider including xmin and xmax as well.
> >> 
> >> If you do that, you'll never be able to delete or update the tuple.
> 
> > My idea was to use an int to represent combinations of (c|x)(min|max),
> > probably on a per-table basis. Essentially, it would normalize these
> > values. I don't see how this would eliminate the ability to update or
> > delete.
> 
> How will other transactions know whether the tuple is good (yet) or not?
> How will you recover if the backend that does know this crashes before
> transaction end?  How will you lock tuples for update/delete?

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. Any time the backend would update any of those
fields it would now insert a new row into visibility containing the
proper values and use vis_id in the tuples.
-- 
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