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 8151611F6AF6 for ; Wed, 19 Apr 2006 01:47:47 -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 MEWmfq4w-+VH for ; Wed, 19 Apr 2006 01:47:44 -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 89E8411F69CB for ; Wed, 19 Apr 2006 01:47:43 -0300 (ADT) Received: from smtp-1.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 <0IXY00MSSDBH61@linda-4.paradise.net.nz> for pgsql-performance@postgresql.org; Wed, 19 Apr 2006 16:47:41 +1200 (NZST) Received: from [192.168.1.11] (218-101-29-147.dsl.clear.net.nz [218.101.29.147]) by smtp-1.paradise.net.nz (Postfix) with ESMTP id C3774FF8BF1; Wed, 19 Apr 2006 16:47:40 +1200 (NZST) Date: Wed, 19 Apr 2006 16:47:40 +1200 From: Mark Kirkwood Subject: Re: merge>hash>loop In-reply-to: <20060418231552.GN49405@pervasive.com> To: "Jim C. Nasby" Cc: Tom Lane , Markus Schaber , pgsql-performance@postgresql.org Message-id: <4445C0EC.2060407@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> X-Archive-Number: 200604/415 X-Sequence-Number: 18499 Jim C. Nasby wrote: > On Tue, Apr 18, 2006 at 06:22:26PM -0400, Tom Lane wrote: >> "Jim C. Nasby" writes: >>> Actually, if you run with stats_block_level turned on you have a >>> first-order approximation of what is and isn't cached. >> Only if those stats decayed (pretty fast) with time; which they don't. > > 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 - what buffers from what relation are in shared_buffers (if you want to interrogate the os file buffer cache, that's a different story - tho I've been toying with doing a utility for Freebsd that would do this). Cheers Mark