Re: compute_query_id and pg_stat_statements
От | Bruce Momjian |
---|---|
Тема | Re: compute_query_id and pg_stat_statements |
Дата | |
Msg-id | 20210426170021.GU7629@momjian.us обсуждение исходный текст |
Ответ на | Re: compute_query_id and pg_stat_statements (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: compute_query_id and pg_stat_statements
|
Список | pgsql-hackers |
On Mon, Apr 26, 2021 at 12:56:13PM -0400, Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: > > * Bruce Momjian (bruce@momjian.us) wrote: > >> Techically, pg_stat_statements can turn on compute_query_id when it is > >> loaded, even if it is 'off' in postgresql.conf, right? And > >> pg_stat_statements would know if an alternate hash method is being used, > >> right? > > > +1 on this approach. > > That'd make it impossible to turn off or adjust afterwards, wouldn't it? > I'm afraid the confusion stemming from that would outweigh any simplicity. > > I would be in favor of logging a message at startup to the effect of > "this is misconfigured" (as per upthread discussion), although whether > people would see that is uncertain. I think a user-visible warning at CREATE EXNTENSION would help too. > In the end, it's not like this is the first time we've ever made an > incompatible change in configuration needs; and it won't be the last > either. I don't buy the argument that pg_stat_statements users can't > cope with adding the additional setting. (Of course, we should be > careful to call it out as an incompatible change in the release notes.) Agreed. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
В списке pgsql-hackers по дате отправления: