Re: pg_stat_statements and "IN" conditions
От | Dmitry Dolgov |
---|---|
Тема | Re: pg_stat_statements and "IN" conditions |
Дата | |
Msg-id | 20230209151226.nwt56axfcu5y3wpr@ddolgov.remote.csb обсуждение исходный текст |
Ответ на | Re: pg_stat_statements and "IN" conditions (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: pg_stat_statements and "IN" conditions
|
Список | pgsql-hackers |
> On Thu, Feb 09, 2023 at 02:30:34PM +0100, Peter Eisentraut wrote: > On 07.02.23 21:14, Sergei Kornilov wrote: > > It seems a little strange to me that with const_merge_threshold = 1, such a test case gives the same result as with const_merge_threshold= 2 > > What is the point of making this a numeric setting? Either you want to > merge all values or you don't want to merge any values. At least in theory the definition of "too many constants" is different for different use cases and I see allowing to configure it as a way of reducing the level of surprise here. The main scenario for a numerical setting would be to distinguish between normal usage with just a handful of constants (and the user expecting to see them represented in pgss) and some sort of outliers with thousands of constants in a query (e.g. as a defence mechanism for the infrastructure working with those metrics). But I agree that it's not clear how much value is in that. Not having strong opinion about this I would be fine changing it to a boolean option (with an actual limit hidden internally) if everyone agrees it fits better.
В списке pgsql-hackers по дате отправления: