Re: pg_stat_statements and "IN" conditions
От | Dmitry Dolgov |
---|---|
Тема | Re: pg_stat_statements and "IN" conditions |
Дата | |
Msg-id | 20230704190256.arszjcwvrjekxj25@ddolgov.remote.csb обсуждение исходный текст |
Ответ на | Re: pg_stat_statements and "IN" conditions (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: pg_stat_statements and "IN" conditions
Re: pg_stat_statements and "IN" conditions Re: pg_stat_statements and "IN" conditions |
Список | 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?
В списке pgsql-hackers по дате отправления: