Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

On Fri, Nov 16, 2018 at 10:11 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Sure. But as soon as they know that, they're just going to try to
figure out how to get the thing they want without the stuff they don't
want.

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

That's just wishful thinking. People will want to know what it does,
they'll want that to be documented, and they complain if it changes
from release to release.

I mean, you've often taken the position that people will notice and/or
care deeply if our *C* interfaces change from release to release, and
even moreso in a minor release. I think you overstate that danger,
but it must be admitted that the danger is not zero. GUCs, unlike C
functions, are unarguably part of the exposed interface, and the
danger there is considerably more, at least IMHO.

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

True. So then you'll have people who can't get sufficiently-high
collapse limits without enabling a bunch of other stuff they don't
care about, or on the other hand have to raise the collapse limits
higher than makes sense for them to get the other optimizations that
they want. They also won't be able to use the hack where you set
join_collapse_limit=1 to force a join ordering any more. And the
mapping of the 1..infinity collapse limit space onto the 1..10 planner
effort space is going to be basically totally arbitrary. There is no
hope at all that you're going to pick values that everyone likes.

I think it might be reasonable to set various individual GUCs to
values that mean "use the autoconfigure default" and then provide a
planner-strength GUC that varies that default. But I believe that
depriving people of the ability to control the settings individually
is bound to produce complaints, both for things where we already
expose them (like the collapse limits) and for things where we don't
(like $SUBJECT).

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