Re: pg_stat_statements and "IN" conditions
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Zhihong Yu <zyu@yugabyte.com>, David Steele <david@pgmasters.net>,
PostgreSQL-development <pgsql-hackers@postgresql.org>, Greg Stark <stark@mit.edu>, Pavel Trukhanov <pavel.trukhanov@gmail.com>
Date: 2022-03-14T15:02:16Z
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
On Mon, Mar 14, 2022 at 10:57 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote: > Well, yeah, the commit message is somewhat clumsy in this regard. It > works almost in the way you've described, except if the list is all > constants and long enough to satisfy the threshold then *first N > elements (where N == threshold) will be jumbled -- to leave at least > some traces of it in pgss. But that seems to me to be a thing we would not want. Why do you think otherwise? > I'm not sure if I follow the last point. WHERE x in (1,3) and x = > any(array[1,3]) are two different things for sure, but in which way are > they going to be mixed together because of this change? My goal was to > make only the following transformation, without leaving any uncertainty: > > WHERE x in (1, 2, 3, 4, 5) -> WHERE x in (1, 2, ...) > WHERE x = any(array[1, 2, 3, 4, 5]) -> WHERE x = any(array[1, 2, ...]) I understand. I think it might be OK to transform both of those things, but I don't think it's very clear either from the comments or the nonexistent documentation that both of those cases are affected -- and I think that needs to be clear. Not sure exactly how to do that, just saying that we can't add behavior unless it will be clear to users what the behavior is. > Sure, I'll add documentation. To be honest I'm not targeting PG15 with > this, just want to make some progress. wfm! -- Robert Haas EDB: http://www.enterprisedb.com