On Tue, Sep 06, 2005 at 06:02:27PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq