Re: [HACKERS] Slow count(*) again...

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Re: [HACKERS] Slow count(*) again...
Дата
Msg-id 4D4B5628.8030100@catalyst.net.nz
обсуждение исходный текст
Ответ на Re: [HACKERS] Slow count(*) again...  (Jeremy Harris <jgh@wizmail.org>)
Список pgsql-performance
On 04/02/11 13:49, Jeremy Harris wrote:
On 2011-02-03 21:51, Mark Kirkwood wrote:
The cases I've seen in production typically involve "outgrowing" optimizer parameter settings: (e.g work_mem, effective_cache_size) as the application dataset gets bigger over time.

An argument in favour of the DBMS maintaining a running estimate of such things.

That is an interesting idea - I'm not quite sure how it could apply to server config settings (e.g work_mem) for which it would be dangerous to allow the server to increase on the fly, but it sure would be handy to have some sort of query execution "memory" so that alerts like:

"STATEMENT: SELECT blah  : PARAMETERS blah: using temp file(s), last execution used memory"

could be generated (this could be quite complex I guess, requiring some sort of long lived statement plan cache).

Cheers

Mark

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

Предыдущее
От: Grant Johnson
Дата:
Сообщение: Re: [HACKERS] Slow count(*) again...
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Slow count(*) again...