Re: optimization ideas for frequent, large(ish) updates

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: optimization ideas for frequent, large(ish) updates
Дата
Msg-id 17527.1076902128@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: optimization ideas for frequent, large(ish) updates  ("Marinos J. Yannikos" <mjy@geizhals.at>)
Список pgsql-performance
"Marinos J. Yannikos" <mjy@geizhals.at> writes:
> Jeff Trout wrote:
>> Remember that it is going to allocate 800MB per sort.

> I didn't know that it always allocates the full amount of memory
> specificed in the configuration

It doesn't ... but it could use *up to* that much before starting to
spill to disk.  If you are certain your sorts won't use that much,
then you could set the limit lower, hm?

Also keep in mind that sort_mem controls hash table size as well as sort
size.  The hashtable code is not nearly as accurate as the sort code
about honoring the specified limit exactly.  So you really oughta figure
that you could need some multiple of sort_mem per active backend.

            regards, tom lane

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

Предыдущее
От: "Marinos J. Yannikos"
Дата:
Сообщение: Re: optimization ideas for frequent, large(ish) updates
Следующее
От: David Teran
Дата:
Сообщение: select max(id) from aTable is very slow