Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: jtc331(at)gmail(dot)com
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Convert MAX_SAOP_ARRAY_SIZE to new guc
Date: 2018-11-16 14:27:43
Message-ID: CANP8+j+whYAQ3wBja4vwXD6GCbJzCvMaMpLmSF8zdAGf85Xrvw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2018-11-16 14:38:26 Re: pg11.1 jit segv
Previous Message James Coleman 2018-11-16 14:00:27 Re: Convert MAX_SAOP_ARRAY_SIZE to new guc