Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

On Fri, 16 Nov 2018 at 14:00, James Coleman <jtc331(at)gmail(dot)com> wrote:

> > > My main comment is that the description of the purpose of the GUC
> doesn't
> > > help me understand when or why I might want to alter it from the
> default
> > > value. If nobody is going to alter it, because nobody understands it,
> it
> > > might as well remain a compile-time constant.
> >
> > 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?

Having indexes defined using WHERE NOT NULL is a very important use case.

> Assuming we go that route, I'd propose we still yank the existing todo
> comment about turning it into a GUC.
>

Agreed

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services