Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-06-28 18:40:28
Subject: Re: Propose Beta3 for July
Previous:From: Josh BerkusDate: 2010-06-28 18:30:24
Subject: Propose Beta3 for July

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group