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 →
-
Introduce squashing of constant lists in query jumbling
- 62d712ecfd94 18.0 landed
-
Make documentation builds reproducible
- b0f0a9432d0b 17.0 cited
-
Include values of A_Const nodes in query jumbling
- 9ba37b2cb6a1 16.0 cited
-
Teach planner about more monotonic window functions
- 456fa635a909 16.0 cited
-
Split up guc.c for better build speed and ease of maintenance.
- 0a20ff54f5e6 16.0 cited
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.