Re: pg_stat_statements and "IN" conditions

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

From: Álvaro Herrera <alvherre@alvh.no-ip.org>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>, 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-14T09:36:48Z
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-14, Julien Rouhaud wrote:

> Since the merging is a yes/no option (I think there used to be some discussions
> about having a threshold or some other fancy modes), maybe you could instead
> differentiate the merged version by have 2 constants rather than this "..." or
> something like that?

Maybe the representation can be "($1 /*, ... */)" so that it's obvious
that the array extends beyond the first element but is still
syntactically valid.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"In Europe they call me Niklaus Wirth; in the US they call me Nickel's worth.
 That's because in Europe they call me by name, and in the US by value!"