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: (view raw, whole thread or download thread mbox)
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 
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).


In response to


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-2017 The PostgreSQL Global Development Group