Re: pg_stat_statements and "IN" conditions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_stat_statements and "IN" conditions
Дата
Msg-id 178940.1647271397@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_stat_statements and "IN" conditions  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pg_stat_statements and "IN" conditions
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Mar 14, 2022 at 10:57 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
>> I'm not sure if I follow the last point. WHERE x in (1,3) and x =
>> any(array[1,3]) are two different things for sure, but in which way are
>> they going to be mixed together because of this change? My goal was to
>> make only the following transformation, without leaving any uncertainty:
>>
>> WHERE x in (1, 2, 3, 4, 5) -> WHERE x in (1, 2, ...)
>> WHERE x = any(array[1, 2, 3, 4, 5]) -> WHERE x = any(array[1, 2, ...])

> I understand. I think it might be OK to transform both of those
> things, but I don't think it's very clear either from the comments or
> the nonexistent documentation that both of those cases are affected --
> and I think that needs to be clear.

We've transformed IN(...) to ANY(ARRAY[...]) at the parser stage for a
long time, and this has been visible to users of either EXPLAIN or
pg_stat_statements for the same length of time.  I doubt people are
going to find that surprising.  Even if they do, it's not the query
jumbler's fault.

I do find it odd that the proposed patch doesn't cause the *entire*
list to be skipped over.  That seems like extra complexity and confusion
to no benefit.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Japin Li
Дата:
Сообщение: Re: support for MERGE
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Estimating HugePages Requirements?