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
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 |