Re: Admission Control Policy

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

In response to

Responses

Browse pgsql-hackers by date

  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