Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.
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