Simon Riggs <simon@2ndquadrant.com> writes:
> On Fri, 16 Nov 2018 at 14:00, James Coleman <jtc331@gmail.com> wrote:
>>> Yeah, that's sort of my reaction as well. I also feel like this is a
>>> mighty special case to expose as a separate GUC. There are other magic
>>> effort-limiting constants elsewhere in the planner --- we just added a
>>> new one in e3f005d97, for instance --- and I can't get very excited about
>>> exposing and trying to document them individually. We also have a lot
>>> of existing exposed knobs like join_collapse_limit and the various geqo
>>> parameters, which basically nobody knows how to use, a precedent that
>>> isn't encouraging for adding more.
>> I'd be happy to yank this in favor of my holistic solution to this
>> problem I posted recently on the mailing list [1].
>> [1] https://www.postgresql.org/message-id/flat/CAAaqYe8yKSvzbyu8w-dThRs9aTFMwrFxn_BkTYeXgjqe3CbNjg%40mail.gmail.com
> Not precisely sure what you mean - are you saying that we can just have an
> overall test for NOT NULL, which thereby avoids the need to expand the
> array and therefore dispenses with the GUC completely?
No, he's saying that other thing solves his particular problem.
We certainly have seen other cases where people wished they could adjust
MAX_SAOP_ARRAY_SIZE. I'm just not excited about exposing a GUC that does
exactly that one thing. I'd rather have some more-generic knob that's
not so tightly tied to implementation details.
regards, tom lane