Re: Convert MAX_SAOP_ARRAY_SIZE to new guc - Mailing list pgsql-hackers

From James Coleman
Subject Re: Convert MAX_SAOP_ARRAY_SIZE to new guc
Date
Msg-id CAAaqYe8XwXPnRRkPX_JKqJeEJYy+=L9Bw+chnm=WiGZKUv7YAg@mail.gmail.com
Whole thread Raw
In response to Re: Convert MAX_SAOP_ARRAY_SIZE to new guc  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
>> 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
avoidsthe 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.

I don't think we can avoid expanding the array for other cases (for
example, being able to infer that "foo < 5" for "foo IN (1,2,3,4)". If
we wanted to keep that inference without expanding the array we'd have
to (at minimum, I think) duplicate a lot of the existing inference
logic, but I haven't investigated it much.

So keeping the GUC could allow someone to tune how large an array can
be and still guarantee inferences like "foo < 5". But I'm not sure
that that is as valuable. At least I haven't run into cases where I've
noticed a need for it.

My patch only addresses the IS NOT NULL inference precisely for the
reason you state: we have lots of plans that (unless you tack on an
explicit "foo IS NOT NULL" to your query) the planner decides it can't
use WHERE NOT NULL indexes because it can't currently infer the
correctness of that for large arrays.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Convert MAX_SAOP_ARRAY_SIZE to new guc
Next
From: Robert Haas
Date:
Subject: Re: Convert MAX_SAOP_ARRAY_SIZE to new guc