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 5F5CB9FA2C3; Thu, 11 May 2006 15:03:06 -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 48930-01; Thu, 11 May 2006 15:02:58 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from exchange.g2switchworks.com (mail.g2switchworks.com [63.87.162.25]) by postgresql.org (Postfix) with ESMTP id B7DE09FA278; Thu, 11 May 2006 15:02:58 -0300 (ADT) Received: from 10.10.1.37 ([10.10.1.37]) by exchange.g2switchworks.com ([10.10.1.2]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 May 2006 18:02:57 +0000 Received: from state.g2switchworks.com by mail.g2switchworks.com; 11 May 2006 13:02:57 -0500 Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal From: Scott Marlowe To: "Jim C. Nasby" Cc: Tom Lane , PFC , Mitchell Skinner , pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org In-Reply-To: <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> <20060511171806.GJ99570@pervasive.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1147370576.9755.81.camel@state.g2switchworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 11 May 2006 13:02:57 -0500 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/295 X-Sequence-Number: 19082 On Thu, 2006-05-11 at 12:18, Jim C. Nasby wrote: > 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. > :( http://www.postgresql.org/docs/8.1/interactive/mvcc.html Does the concurrency doc not cover this subject well enough (I'm not being sarcastic, it's a real question)