Re: [PERFORM] Big IN() clauses etc : feature proposal - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: [PERFORM] Big IN() clauses etc : feature proposal
Date
Msg-id 20060511171806.GJ99570@pervasive.com
Whole thread Raw
In response to Re: [PERFORM] Big IN() clauses etc : feature proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PERFORM] Big IN() clauses etc : feature proposal
Re: [PERFORM] Big IN() clauses etc : feature proposal
List 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 by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: sblock state on FreeBSD 6.1
Next
From: Martijn van Oosterhout
Date:
Subject: Re: sblock state on FreeBSD 6.1