| From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Markus Schaber <schabi(at)logix-tt(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: merge>hash>loop |
| Date: | 2006-04-19 04:47:40 |
| Message-ID: | 4445C0EC.2060407@paradise.net.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Jim C. Nasby wrote:
> On Tue, Apr 18, 2006 at 06:22:26PM -0400, Tom Lane wrote:
>> "Jim C. Nasby" <jnasby(at)pervasive(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2006-04-19 05:13:47 | Re: Blocks read for index scans |
| Previous Message | Terje Elde | 2006-04-19 02:35:11 | Re: Blocks read for index scans |