Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

From: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
To: jtc331(at)gmail(dot)com
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Convert MAX_SAOP_ARRAY_SIZE to new guc
Date: 2018-11-15 19:09:07
Message-ID: CACowWR2N=-GuHtLY=6=qZ2yges-JF62xAJi1JX=Spb7ONnM_4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 9, 2018 at 1:32 PM James Coleman <jtc331(at)gmail(dot)com> wrote:

> Summary:
> Create new guc array_optimization_size_limit and use it to replace
> MAX_SAOP_ARRAY_SIZE in predtest.c.
>
> Status:
> The attached patch applies cleanly to master, builds without error,
> and passes tests locally.
>

Confirmed that it applies and builds cleaning and regresses without error
in my environment (osx/clang)

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.

+ <para>
+ Sets the array size limit beyond which predicate optimization is
not used.
+ The optimizer evaluates scalar array expressions to determine if
they can
+ be treated as AND or OR clauses. This optimization proving is only
performed
+ if the array contains at most this many items.
+ The default is <literal>100</literal>.
+ </para>

If I lower the value, what problem or use case do I solve? If I increase
it, what do I solve? What gets faster or slower at different settings of
the value? The description doesn't mention using the "IN" SQL clause which
is the use case the parameter targets. I'd suggest alternate wording, but
I'm actually still not 100% sure how a larger value would change the
behaviour of "IN" in the presence of large numbers of values?

P.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-11-15 19:19:05 Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)
Previous Message Robert Haas 2018-11-15 18:52:29 Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)