On Fri, Dec 12, 2014 at 5:19 AM, Robert Haas <robertmh...@gmail.com> wrote: > Well, this is sort of one of the problems with work_mem. When we > switch to a tape sort, or a tape-based materialize, we're probably far > from out of memory. But trying to set work_mem to the amount of > memory we have can easily result in a memory overrun if a load spike > causes lots of people to do it all at the same time. So we have to > set work_mem conservatively, but then the costing doesn't really come > out right. We could add some more costing parameters to try to model > this, but it's not obvious how to get it right.
I've heard of using "set work_mem = *" with advisory locks plenty of times. There might be a better way to set it dynamically than a full admission control implementation. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
