On Mon, Oct 18, 2010 at 3:55 PM, Tom Lane <[email protected]> wrote: > Robert Haas <[email protected]> writes: >> On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane <[email protected]> wrote: >>> Andres Freund <[email protected]> writes: >>>> Hm. Wouldnt it be possible to use virtual xids for that purpose? They are >>>> never seen outside of that session anyway... >>> >>> Well, maybe, but then you need infrastructure to track whether VXIDs >>> committed or aborted. > >> Seems like this would wreak havoc with the HeapTupleSatisfies* functions. > > Yeah, it would be messy all over. This reminds me of last week's > discussion about mysql-style storage engines --- by the time you made > this work, you'd have something darn close to a separate storage engine > for temp tables. It'd need its own parallel infrastructure covering > everything to do with tuple visibility determination. > > It'd be kinda cool if we had it, but the work required to get there > seems far out of proportion to the benefits ...
I agree. I think that's backing into the problem from the wrong end. The limiting factor here is that we require the entire cluster to be replicated. If you could replicate individual tables/schemas, then this problem disappears. Of course, that's not easy either, but if you're going to solve a really hard problem, you might as well pick that one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
