Re: pg_stat_statements and "IN" conditions

Dmitry Dolgov <9erthalion6@gmail.com>

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-13T16:50:09Z
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 Thu, Feb 13, 2025 at 01:47:01PM GMT, Álvaro Herrera wrote:
> Also, how wed are you to
> "query_id_merge_values" as a name?  It's not in any way obvious that
> this is about values in arrays.  How about query_id_squash_arrays?  Or
> are you thinking in having values in other types of structures squashed
> as well, and that this first patch does it for arrays only but you want
> the GUC to also control some future feature?
>
> (I think I prefer "squash" here as a verb to "merge").

Yeah, when choosing the name I was trying to keep it a bit generic. The
high level goal is to reduce repeated non-essential parts, and arrays of
constants are one clear scenario, but there could be more to it. Having
said that I don't have any particular plans for extending this logic so
far. I've ended up with query_id_squash_values, how does this sound?

> I think calling func_volatile potentially once per array element is not
> good; this might cause dozens/thousands of identical syscache lookups.
> Maybe we can pass an initially NIL list from IsMergeableConstList (as
> List **), which IsMergeableConst fills with OIDs of functions that have
> been checked and found acceptable.  Then the second time around we
> search the list first and only do func_volatile() after not finding a
> match.

Good point, added.

> Another thing I didn't quite understand is why you did this rather
> baroque-looking list scan:

I'm pretty sure there was some reason behind it, but when you pointed it
out that reason has promptly vanished in a puff of confusion. Fixed.