X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id D0CF89FA2C3; Thu, 11 May 2006 14:18:15 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 43223-04; Thu, 11 May 2006 14:18:09 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 3F9279FA19B; Thu, 11 May 2006 14:18:09 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 0E16156423; Thu, 11 May 2006 12:18:08 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Thu, 11 May 2006 12:18:06 -0500 Date: Thu, 11 May 2006 12:18:06 -0500 From: "Jim C. Nasby" To: Tom Lane Cc: PFC , Mitchell Skinner , pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal Message-ID: <20060511171806.GJ99570@pervasive.com> References: <20060509113337.M90693@vesihiisi.cksoft.de> <20060509103632.GD29652@svana.org> <1147190285.32304.43.camel@firebolt> <16680.1147201981@sss.pgh.pa.us> <20060510190011.GO99570@pervasive.com> <22558.1147307514@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22558.1147307514@sss.pgh.pa.us> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060511:tgl@sss.pgh.pa.us::DLH32YqxBy8/Z/xv:00000000000000000000 0000000000000000000000004/uu X-Hashcash: 1:20:060511:lists@peufeu.com::EV3XS0wuSbcssPdG:02QEw X-Hashcash: 1:20:060511:mitch@arctur.us::TlYxXSYELoeEhlGP:000cCE X-Hashcash: 1:20:060511:pgsql-performance@postgresql.org::Buh7YfsrlCmyuSSA:00000 00000000000000000000000018ja X-Hashcash: 1:20:060511:pgsql-hackers@postgresql.org::RosOvgP9IluLZgaB:000000000 0000000000000000000000004Cu2 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/294 X-Sequence-Number: 19081 On Wed, May 10, 2006 at 08:31:54PM -0400, Tom Lane wrote: > "Jim C. Nasby" writes: > > On Tue, May 09, 2006 at 03:13:01PM -0400, Tom Lane wrote: > >> PFC 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