On Mon, Oct 18, 2010 at 3:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Andres Freund <andres@anarazel.de> 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
