Horton

Re: pg_stat_statements and "IN" conditions

Dmitry Dolgov <9erthalion6@gmail.com>

View thread
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Álvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Sami Imseih <samimseih@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:35:35Z
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 Tue, Feb 11, 2025 at 10:49:59AM GMT, Sami Imseih wrote:
> I have only looked at 0001, but I am wondering why
> query_id_const_merge is a pg_stat_statements GUC
> rather than a core GUC?

It was moved from being a core GUC into a pg_stat_statements GUC on the request
from the reviewers. Community tries to prevent adding more and more core GUCs
into PostgreSQL.

> On Tue, Feb 11, 2025 at 07:18:23PM GMT, Álvaro Herrera wrote:
> 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.)

Yes, those cases in question are usually FuncExpr. The original patch
implementation used to handle that via simplifying the node with
eval_const_expressions to figure out if the value we work with is a constant.
This approach was marked as too risky by reviewers, as this could reach a lot
of unexpected functionality in the mutator part.