Re: Creation of temporary tables on read-only standby servers
От | Robert Haas |
---|---|
Тема | Re: Creation of temporary tables on read-only standby servers |
Дата | |
Msg-id | AANLkTikE7Zib0hiXO10C89sm=43bXM4p-qGS_XkX-rk9@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Creation of temporary tables on read-only standby servers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Creation of temporary tables on read-only standby servers
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: