Re: optimization ideas for frequent, large(ish) updates
В списке pgsql-performance по дате отправления:
| От | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера