From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: Creation of temporary tables on read-only standby servers |
Date: | 2010-10-18 19:55:10 |
Message-ID: | 24723.1287431710@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Oct 18, 2010 at 3:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Andres Freund <andres(at)anarazel(dot)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 ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-10-18 20:02:01 | Re: create tablespace fails silently, or succeeds improperly |
Previous Message | Tom Lane | 2010-10-18 19:50:58 | Re: create tablespace fails silently, or succeeds improperly |