Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

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

I don't think so, because right now they (a) can't get either
optimization, and/or (b) don't know what either one does or
how to invoke it.

Also (c) exposing such knobs creates backwards-compatibility problems for
us any time we want to change the associated behavior, which is hardly
an unlikely wish considering that mostly these are kluges by definition.
(Which contributes to the documentation problem Paul already noted.)

A planner-effort knob would be really easy to understand, I think,
and we'd not be tied to any particular details about what it does.

> The stuff that people have proposed grouping under a planner
> effort knob is all pretty much corner case behavior,

One of the first things I'd replace with such a knob is
join_collapse_limit/from_collapse_limit, which is by no stretch
of the imagination a corner case.

> 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.

Yeah, it's unlikely that it'd be linear on any particular query.
There would be jumps in the planner runtime whenever relevant
thresholds were exceeded.

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

> +1 for that, though.

It's tempting to imagine that 10 means "highest reasonable effort
limits" and then 11 disengages all limits. The practical use of
that would be if you wanted to see whether the planner *could*
produce the plan you wanted and was just not trying hard enough.

regards, tom lane