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 821B19FA3A3; Wed, 10 May 2006 21:32:08 -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 60358-01; Wed, 10 May 2006 21:32:04 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 4B18D9F931E; Wed, 10 May 2006 21:32:04 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k4B0VsjW022559; Wed, 10 May 2006 20:31:54 -0400 (EDT) To: "Jim C. Nasby" cc: PFC , Mitchell Skinner , pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal In-reply-to: <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> <20060510190011.GO99570@pervasive.com> Comments: In-reply-to "Jim C. Nasby" message dated "Wed, 10 May 2006 14:00:11 -0500" Date: Wed, 10 May 2006 20:31:54 -0400 Message-ID: <22558.1147307514@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/283 X-Sequence-Number: 19070 "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). > 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. regards, tom lane