Re: merge>hash>loop

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Re: merge>hash>loop
Дата
Msg-id 4445CB8E.5020800@paradise.net.nz
обсуждение исходный текст
Ответ на Re: merge>hash>loop  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Tom Lane wrote:
> Mark Kirkwood <markir@paradise.net.nz> 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

В списке pgsql-performance по дате отправления:

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: Blocks read for index scans
Следующее
От: Theo Kramer
Дата:
Сообщение: Re: Multicolumn order by