Re: Enforce work_mem per worker

Поиск
Список
Период
Сортировка
От Arne Roland
Тема Re: Enforce work_mem per worker
Дата
Msg-id 1d30435d2cc34940a79967a3f12ed95f@index.de
обсуждение исходный текст
Ответ на Re: Enforce work_mem per worker  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Enforce work_mem per worker  (Justin Pryzby <pryzby@telsasoft.com>)
Список pgsql-hackers

I did read parts of the last one back then. But thanks for the link, I plan to reread the thread as a whole.


From what I can tell, the discussions here are the attempt by very smart people to (at least partially) solve the problem of memory allocation (without sacrificing to much on the runtime front). That problem is very hard.


What I am mostly trying to do, is to provide a reliable way of preventing the operational hazard of dealing with oom and alike, e.g. massive kernel buffer eviction. I don't want to touch the planning, which is always complex and tends to introduce weird side effects.


That way we can't hope to prevent the issue from occurring generally. I'm much more concerned with containing it, if it happens.


In the case that there is only a single pass, which tends to be the case for a lot of queries, my suggested approach would even help the offender.

But my main goal is something else. I can't explain my clients, why a chanced statistics due to autovacuum suddenly leads to oom. They would be right to question postgres qualification for any serious production system.


Regards

Arne


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

Предыдущее
От: Guillaume Lelarge
Дата:
Сообщение: Lots of memory allocated when reassigning Large Objects
Следующее
От: Andrei Zubkov
Дата:
Сообщение: [PATCH] pg_statio_all_tables: several rows per table due to invalid TOAST index