Re: pg_stat_statements and "IN" conditions
Dmitry Dolgov <9erthalion6@gmail.com>
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: David Geier <geidav.pg@gmail.com>
Cc: Sergei Kornilov <sk@zsrv.org>, Michael Paquier <michael@paquier.xyz>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Marcos Pegoraro <marcos@f10.com.br>, vignesh C <vignesh21@gmail.com>, Robert Haas <robertmhaas@gmail.com>, 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>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2023-02-11T12:08:20Z
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 Sat, Feb 11, 2023 at 11:47:07AM +0100, Dmitry Dolgov wrote: > > The original version of the patch was doing all of this, i.e. handling > numerics, Param nodes, RTE_VALUES. The commentary about > find_const_walker in tests is referring to a part of that, that was > dealing with evaluation of expression to see if it could be reduced to a > constant. > > Unfortunately there was a significant push back from reviewers because > of those features. That's why I've reduced the patch to it's minimally > useful version, having in mind re-implementing them as follow-up patches > in the future. This is the reason as well why I left tests covering all > this missing functionality -- as breadcrumbs to already discovered > cases, important for the future extensions. I'd like to elaborate on this a bit and remind about the origins of the patch, as it's lost somewhere in the beginning of the thread. The idea is not pulled out of thin air, everything is coming from our attempts to improve one particular monitoring infrastructure in a real commercial setting. Every covered use case and test in the original proposal was a result of field trials, when some application-side library or ORM was responsible for gigabytes of data in pgss, chocking the monitoring agent.