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