Re: Convert MAX_SAOP_ARRAY_SIZE to new guc

Поиск
Список
Период
Сортировка
От James Coleman
Тема Re: Convert MAX_SAOP_ARRAY_SIZE to new guc
Дата
Msg-id CAAaqYe8XwXPnRRkPX_JKqJeEJYy+=L9Bw+chnm=WiGZKUv7YAg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Convert MAX_SAOP_ARRAY_SIZE to new guc  (Simon Riggs <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Convert MAX_SAOP_ARRAY_SIZE to new guc
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Convert MAX_SAOP_ARRAY_SIZE to new guc