On Mon, Dec 28, 2009 at 3:33 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > They describe a two-tier approach, where the first tier is already > effectively implemented in PostgreSQL with the max_connections and > superuser_reserved_connections GUCs. The second tier is implemented > to run after a plan is chosen, and may postpone execution of a query > (or reduce the resources it is allowed) if starting it at that time > might overload available resources.
It seems like it might be helpful, before tackling what you're talking about here, to have some better tools for controlling resource utilization. Right now, the tools we have a pretty crude. You can't even nice/ionice a certain backend without risking priority inversion, and there's no sensible way to limit the amount of amount of working memory per-query, only per query-node. http://archives.postgresql.org/pgsql-hackers/2009-10/msg00125.php ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
