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 5821C9FA2CB; Wed, 10 May 2006 16:00:33 -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 48483-07; Wed, 10 May 2006 16:00:16 -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 F32629FA293; Wed, 10 May 2006 16:00:15 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id B817D56427; Wed, 10 May 2006 14:00:12 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Wed, 10 May 2006 14:00:11 -0500 Date: Wed, 10 May 2006 14:00:11 -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: <20060510190011.GO99570@pervasive.com> References: <20060509105214.P90693@vesihiisi.cksoft.de> <20060509113337.M90693@vesihiisi.cksoft.de> <20060509103632.GD29652@svana.org> <1147190285.32304.43.camel@firebolt> <16680.1147201981@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16680.1147201981@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:060510:tgl@sss.pgh.pa.us::fd6cOBf4ergK/nuR:00000000000000000000 00000000000000000000000023Ug X-Hashcash: 1:20:060510:lists@peufeu.com::WL9oOPhGeGPRqCIG:01v47 X-Hashcash: 1:20:060510:mitch@arctur.us::Bdrl+NcGdKAyrsoD:000tI+ X-Hashcash: 1:20:060510:pgsql-performance@postgresql.org::UHKHVD+uGfIV6Ss2:00000 000000000000000000000000108s X-Hashcash: 1:20:060510:pgsql-hackers@postgresql.org::RiG0QYuTB4ETpn7Q:000000000 00000000000000000000000016cX X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/267 X-Sequence-Number: 19054 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? Even if you rollback you should still be able to just update a row counter because nothing else would be able to see what was rolled back. 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? -- 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