Re: Admission Control

From: Jesper Krogh <jesper(at)krogh(dot)cc>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Admission Control
Date: 2010-06-28 18:32:10
Message-ID: 4C28EAAA.7030400@krogh.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2010-06-25 22:44, Robert Haas wrote:
> On Fri, Jun 25, 2010 at 3:52 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>
>> Heck, I think an even *more* trivial admission control policy which
>> limits the number of active database transactions released to
>> execution might solve a lot of problems.
>>
> That wouldn't have any benefit over what you can already do with a
> connection pooler, though, I think. In fact, it would probably be
> strictly worse, since enlarging the number of backends slows the
> system down even if they aren't actually doing anything much.
>

Sorry if I'm asking silly questions, but how does transactions and
connection pooler's interact?

Say if you have 100 clients all doing "fairly inactive" database work
in transactions lasting a couple of minutes at the same time. If I
understand
connection poolers they dont help much in those situations where an
"accounting" system on "limited resources" across all backends
definately would help.

(yes, its a real-world application here, wether it is clever or not... )

In a fully web environment where all transaction last 0.1s .. a pooler
might make fully sense (when traffic goes up).

--
Jesper

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-06-28 18:40:28 Re: Propose Beta3 for July
Previous Message Josh Berkus 2010-06-28 18:30:24 Propose Beta3 for July