From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(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 19:02:56 |
Message-ID: | 20230704190256.arszjcwvrjekxj25@ddolgov.remote.csb |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Mon, Jul 03, 2023 at 09:46:11PM -0700, Nathan Bossart wrote:
Thanks for reviewing.
> 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.
This documentation is exclusively to be precise about how does it work.
Users don't have to worry about all this, and pretty much turn it
on/off, as you've described. I agree though, I could probably write this
text a bit differently.
> 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.
Independently of what Álvaro was suggesting, I find the "powers"
approach more suitable, because it answers my own concerns about the
previous implementation. Having "on"/"off" values means we would have to
scratch heads coming up with a one-size-fit-all default value, or to
introduce another option for the actual cut-off threshold. I would like
to avoid both of those options, that's why I went with "powers" only.
> Also, it seems counterintuitive that queries with fewer than 10
> constants are not merged.
Why? What would be your intuition using this feature?
> 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.
I would disagree. As I've described above, to me "powers" seems to be a
better fit, and the complicated logic is in fact reusing one already
existing function. Do those arguments sound convincing to you?
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2023-07-04 19:08:39 | Re: Reducing connection overhead in pg_upgrade compat check phase |
Previous Message | Tom Lane | 2023-07-04 18:40:04 | Re: Add more sanity checks around callers of changeDependencyFor() |