From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Admission Control Policy |
Date: | 2009-12-29 00:01:13 |
Message-ID: | 603c8f070912281601s701567ben4cb4e60bbfe1f306@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 28, 2009 at 3:33 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-12-29 00:05:12 | Re: Admission Control Policy |
Previous Message | Thomas Kellerer | 2009-12-28 23:57:42 | Re: 8.4.1 ubuntu karmic slow createdb |