X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 4008D11F608D for ; Wed, 19 Apr 2006 02:33:56 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: 0.12 X-Spam-Level: X-Spam-Status: No, score=0.12 required=5 tests=[AWL=0.120] Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id ScYHfk92BNdS for ; Wed, 19 Apr 2006 02:33:51 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from linda-4.paradise.net.nz (bm-4a.paradise.net.nz [203.96.152.183]) by postgresql.org (Postfix) with ESMTP id B5B3611F6003 for ; Wed, 19 Apr 2006 02:33:47 -0300 (ADT) Received: from smtp-3.paradise.net.nz (tclsnelb1-src-1.paradise.net.nz [203.96.152.172]) by linda-4.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IXY000RRFF3NB@linda-4.paradise.net.nz> for pgsql-performance@postgresql.org; Wed, 19 Apr 2006 17:33:03 +1200 (NZST) Received: from [192.168.1.11] (218-101-29-147.dsl.clear.net.nz [218.101.29.147]) by smtp-3.paradise.net.nz (Postfix) with ESMTP id 16ABA7B0C4B; Wed, 19 Apr 2006 17:33:03 +1200 (NZST) Date: Wed, 19 Apr 2006 17:33:02 +1200 From: Mark Kirkwood Subject: Re: merge>hash>loop In-reply-to: <22250.1145424328@sss.pgh.pa.us> To: Tom Lane Cc: "Jim C. Nasby" , Markus Schaber , pgsql-performance@postgresql.org Message-id: <4445CB8E.5020800@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit User-Agent: Thunderbird 1.5 (X11/20060417) References: <1145029009.3422.31.camel@spectre.intellivid.com> <10000.1145031205@sss.pgh.pa.us> <1145033149.3422.41.camel@spectre.intellivid.com> <11035.1145033929@sss.pgh.pa.us> <4444C4CF.2000106@logix-tt.com> <20060418215238.GK49405@pervasive.com> <19388.1145398946@sss.pgh.pa.us> <20060418231552.GN49405@pervasive.com> <4445C0EC.2060407@paradise.net.nz> <22250.1145424328@sss.pgh.pa.us> X-Archive-Number: 200604/420 X-Sequence-Number: 18504 Tom Lane wrote: > Mark Kirkwood writes: >> Jim C. Nasby wrote: >>> Good point. :/ I'm guessing there's no easy way to see how many blocks >>> for a given relation are in shared memory, either... > >> contrib/pg_buffercache will tell you this - > > I think the key word in Jim's comment was "easy", ie, cheap. Grovelling > through many thousands of buffers to count the matches to a given > relation doesn't sound appetizing, especially not if it gets done over > again several times during each query-planning cycle. Trying to keep > centralized counts somewhere would be even worse (because of locking/ > contention issues). > Yeah - not sensible for a transaction oriented system - might be ok for DSS tho. Cheers mark