Robert Haas <robertmh...@gmail.com> wrote: > Kevin Grittner <kevin.gritt...@wicourts.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
