Re: merge>hash>loop - Mailing list pgsql-performance

From Mark Kirkwood
Subject Re: merge>hash>loop
Date
Msg-id 4445C0EC.2060407@paradise.net.nz
Whole thread Raw
In response to Re: merge>hash>loop  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: merge>hash>loop  ("Jim C. Nasby" <jnasby@pervasive.com>)
Re: merge>hash>loop  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Jim C. Nasby wrote:
> On Tue, Apr 18, 2006 at 06:22:26PM -0400, Tom Lane wrote:
>> "Jim C. Nasby" <jnasby@pervasive.com> 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

pgsql-performance by date:

Previous
From: Terje Elde
Date:
Subject: Re: Blocks read for index scans
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Blocks read for index scans