Re: pg_stat_statements and "IN" conditions

Поиск
Список
Период
Сортировка
От Álvaro Herrera
Тема Re: pg_stat_statements and "IN" conditions
Дата
Msg-id 202502111818.tbs5d7l5bvle@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: pg_stat_statements and "IN" conditions  (Sami Imseih <samimseih@gmail.com>)
Ответы Re: pg_stat_statements and "IN" conditions
Список pgsql-hackers
On 2025-Feb-11, Sami Imseih wrote:

> I do not have an explanation from the patch yet, but I have a test
> that appears to show unexpected results. I only tested a few datatypes,
> but from what I observe, some merge as expected and others do not;
> i.e. int columns merge correctly but bigint do not.

Yep, I noticed this too, and realized that this is because these values
are wrapped in casts of some sort, while the others are not.

> select from foo where col_bigint in (1, 2, 3);
> select from foo where col_bigint in (1, 2, 3, 4);
> select from foo where col_bigint in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
> select from foo where col_float in (1, 2, 3);
> select from foo where col_float in (1, 2, 3, 4);

You can see that it works correctly if you use quotes around the values,
e.g.
select from foo where col_float in ('1', '2', '3');
select from foo where col_float in ('1', '2', '3', '4');
and so on.  There are no casts here because these literals are of type
unknown.

I suppose this is telling us that detecting the case with consts wrapped
in casts is not really optional.  (Dmitry said this was supported at
early stages of the patch, and now I'm really curious about that
implementation because what IsMergeableConstList sees is a FuncExpr that
invokes the cast function for float8 to int4.)

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"La fuerza no está en los medios físicos
sino que reside en una voluntad indomable" (Gandhi)



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