Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> check out section 2.4 of this
> A really trivial admission control system might let you set a
> system-wide limit on work_mem.
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. Of course, what you
propose is more useful, although I'd be inclined to think that we'd
want an admission control layer which could be configured so support
both of these and much more. Done correctly, it could almost
completely eliminate the downward slope after you hit the "knee" in
many performance graphs.
> A refinement might be to try to consider an inferior plan that
> uses less memory when the system is tight on memory, rather than
> waiting.
I wouldn't try messing with that until we have the basics down. ;-)
It is within the scope of what an execution admission controller is
intended to be able to do, though.
> The idea of doling out queries to engine processes in an
> interesting one, but seems very different than our current query
> execution model.
That wasn't in section 2.4 itself -- you must have read the whole
chapter. I think any discussion of that should spin off a separate
thread -- the techniques are really orthogonal. And frankly, that's
more ambitious a topic than *I'm* inclined to want to get into at
the moment. An "execution admission controller" that starts simple
but leaves room for growth seems within the realm of possibility.
-Kevin