Re: merge>hash>loop

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Re: merge>hash>loop
Дата
Msg-id 4445C0EC.2060407@paradise.net.nz
обсуждение исходный текст
Ответ на Re: merge>hash>loop  ("Jim C. Nasby" <jnasby@pervasive.com>)
Ответы Re: merge>hash>loop  ("Jim C. Nasby" <jnasby@pervasive.com>)
Re: merge>hash>loop  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Terje Elde
Дата:
Сообщение: Re: Blocks read for index scans
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Blocks read for index scans