Re: pg_stat_statements and "IN" conditions

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: "Gregory Stark (as CFM)" <stark(dot)cfm(at)gmail(dot)com>, David Geier <geidav(dot)pg(at)gmail(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>, vignesh C <vignesh21(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Pavel Trukhanov <pavel(dot)trukhanov(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: pg_stat_statements and "IN" conditions
Date: 2023-07-04 04:46:11
Message-ID: 20230704044611.GA3373000@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 19, 2023 at 01:27:34PM +0100, Dmitry Dolgov wrote:
> + If this parameter is on, two queries with an array will get the same
> + query identifier if the only difference between them is the number of
> + constants, both numbers is of the same order of magnitude and greater or
> + equal 10 (so the order of magnitude is greather than 1, it is not worth
> + the efforts otherwise).

IMHO this adds way too much complexity to something that most users would
expect to be an on/off switch. If I understand Álvaro's suggestion [0]
correctly, he's saying that in addition to allowing "on" and "off", it
might be worth allowing something like "powers" to yield roughly the
behavior described above. I don't think he's suggesting that this "powers"
behavior should be the only available option. Also, it seems
counterintuitive that queries with fewer than 10 constants are not merged.

In the interest of moving this patch forward, I would suggest making it a
simple on/off switch in 0002 and moving the "powers" functionality to a new
0003 patch. I think separating out the core part of this feature might
help reviewers. As you can see, I got distracted by the complicated
threshold logic and ended up focusing my first round of review there.

[0] https://postgr.es/m/20230209172651.cfgrebpyyr72h7fv%40alvherre.pgsql

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2023-07-04 05:19:43 Re: pgsql: Fix search_path to a safe value during maintenance operations.
Previous Message Thomas Munro 2023-07-04 04:22:40 Re: DSA failed to allocate memory