Horton

Re: pg_stat_statements and "IN" conditions

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread
From: Álvaro Herrera <alvherre@alvh.no-ip.org>
To: Sami Imseih <samimseih@gmail.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>, Sergei Kornilov <sk@zsrv.org>, yasuo.honda@gmail.com, tgl@sss.pgh.pa.us, smithpb2250@gmail.com, vignesh21@gmail.com, michael@paquier.xyz, nathandbossart@gmail.com, stark.cfm@gmail.com, geidav.pg@gmail.com, marcos@f10.com.br, robertmhaas@gmail.com, david@pgmasters.net, pgsql-hackers@postgresql.org, pavel.trukhanov@gmail.com, Sutou Kouhei <kou@clear-code.com>
Date: 2025-02-11T18:18:23Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Introduce squashing of constant lists in query jumbling

  2. Make documentation builds reproducible

  3. Include values of A_Const nodes in query jumbling

  4. Teach planner about more monotonic window functions

  5. Split up guc.c for better build speed and ease of maintenance.

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)