Re: [PERFORM] Big IN() clauses etc : feature proposal
От | Jim C. Nasby |
---|---|
Тема | Re: [PERFORM] Big IN() clauses etc : feature proposal |
Дата | |
Msg-id | 20060511171806.GJ99570@pervasive.com обсуждение исходный текст |
Ответ на | Re: [PERFORM] Big IN() clauses etc : feature proposal (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PERFORM] Big IN() clauses etc : feature proposal
Re: [PERFORM] Big IN() clauses etc : feature proposal |
Список | pgsql-hackers |
On Wed, May 10, 2006 at 08:31:54PM -0400, Tom Lane wrote: > "Jim C. Nasby" <jnasby@pervasive.com> writes: > > On Tue, May 09, 2006 at 03:13:01PM -0400, Tom Lane wrote: > >> PFC <lists@peufeu.com> writes: > >>> Fun thing is, the rowcount from a temp table (which is the problem here) > >>> should be available without ANALYZE ; as the temp table is not concurrent, > >>> it would be simple to inc/decrement a counter on INSERT/DELETE... > >> > >> No, because MVCC rules still apply. > > > But can anything ever see more than one version of what's in the table? > > Yes, because there can be more than one active snapshot within a single > transaction (think about volatile functions in particular). Any documentation on how snapshot's work? They're a big mystery to me. :( > > Speaking of which, if a temp table is defined as ON COMMIT DROP or > > DELETE ROWS, there shouldn't be any need to store xmin/xmax, only > > cmin/cmax, correct? > > No; you forgot about subtransactions. Oh, I thought those were done with cmin and cmax... if that's not what cmin/cmax are for, then what is? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-hackers по дате отправления: