Re: Admission Control - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Admission Control
Date
Msg-id 4C24D4B90200002500032B55@gw.wicourts.gov
Whole thread Raw
In response to Re: Admission Control  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> Kevin Grittner <Kevin.Grittner@wicourts.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.
Agreed -- *if* the connection pool is on another computer. 
Otherwise it'll probably consume about he same resources on the same
machine as what I'm proposing, only with more setup and
configuration involved.  Until we build a connection pooler into the
base product, though, you know what an uphill battle it is to get
people to control contention that way. We can usually get someone to
tweak a GUC when they report a problem, and maybe the tuning tools
could start to take core count and effective spindle count into
consideration and suggest a good setting for this, if we had it.
With the right connection pooler built in to core, though, this one
could go right out the window, and they could tune at that layer
instead.  [thinks]  Actually, the transaction count limit doesn't
need the planner to run first, so it could be considered part of the
first-tier admission control.  Essentially, it *would be* a simple
but effective built-in connection pooler.
I still think an execution admission controller would be worthwhile,
but the policy I proposed doesn't belong there; it might be the
subject of a pretty simple patch which might solve a lot of
performance problems.  Gotta sleep on that....
-Kevin


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: simplifying emode_for_corrupt_record
Next
From: Pavel Baros
Date:
Subject: Re: GSoC - code of implementation of materialized views