Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

On Thu, Nov 15, 2018 at 5:50 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> There have been occasional discussions of inventing a master "planner
> effort" control knob, with values say 1..10 [1], and allowing that one
> thing to control all these decisions, as well as other things we might do
> in the future that would cause increased planning time that might or might
> not get paid back. I'd rather see somebody put effort into designing a
> coherent feature like that than figure out how to document finer-grained
> knobs.

FWIW, I find it hard to believe this will make users very happy. I
think it'll just lead to people complaining that they can't get
planner optimization A without paying the cost of planner optimization
B. The stuff that people have proposed grouping under a planner
effort knob is all pretty much corner case behavior, so a lot of
people won't get any benefit at all from turning up the knob, and
among those that do, there will probably be one specific behavior that
they want to enable, so the optimal value will be just high enough to
enable that behavior, and then they'll wonder why they can't just
enable that one thing.

I do think it would make users happy if you could make it a nice,
smooth curve: turning up the planner strength increases planning time
at a predictable rate and decreases execution time at a predictable
rate. But I really doubt it's possible to create something that works
that way.

> [1] ... but my inner Spinal Tap fan wants it to go to 11.

+1 for that, though.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company