Re: Enforce work_mem per worker - Mailing list pgsql-hackers

From Arne Roland
Subject Re: Enforce work_mem per worker
Date
Msg-id 1d30435d2cc34940a79967a3f12ed95f@index.de
Whole thread Raw
In response to Re: Enforce work_mem per worker  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: Enforce work_mem per worker
List 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 by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Lots of memory allocated when reassigning Large Objects
Next
From: Andrei Zubkov
Date:
Subject: [PATCH] pg_statio_all_tables: several rows per table due to invalid TOAST index