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-13T10:50:14Z
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.

Attachments

> On Wed, Feb 12, 2025 at 08:48:03PM GMT, Dmitry Dolgov wrote:
> > On Wed, Feb 12, 2025 at 07:39:39PM GMT, Álvaro Herrera wrote:
> > The nastiness level of this seems quite low, compared to what happens to
> > this other example if we didn't handle these easy cases:
> >
> > create table t (a float);
> > select i from t where i in (1, 2);
> > select i from t where i in (1, '2');
> > select i from t where i in ('1', 2);
> > select i from t where i in ('1', '2');
> > select i from t where i in (1.0, 1.0);
>
> Yep, the current version I've got so far produces the same
> pg_stat_statements entry for all of those queries. I'm going to move out
> the renamed GUC and post the new patch tomorrow.

Here is how it looks like (posting only the first patch, since we
concentrate on it). This version handles just a little more to cover
simpe cases like the implicit convertion above. The GUC is also moved
out from pgss and renamed to query_id_merge_values. On top I've added
more tests showing the impact, as well as sometimes awkward looking
normalized query I was talking about. I'm going to experiment how to
iron out the latter.