Re: compute_query_id and pg_stat_statements
От | Julien Rouhaud |
---|---|
Тема | Re: compute_query_id and pg_stat_statements |
Дата | |
Msg-id | 20210513015700.fp33q5rfvwl2ahfx@nol обсуждение исходный текст |
Ответ на | Re: compute_query_id and pg_stat_statements (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: compute_query_id and pg_stat_statements
|
Список | pgsql-hackers |
On Wed, May 12, 2021 at 09:13:25PM -0400, Bruce Momjian wrote: > On Thu, May 13, 2021 at 08:52:36AM +0800, Julien Rouhaud wrote: > > > > Well, as implemented you can get the value of compute_query_id, and if it's > > still "auto" then it's not enabled as calling queryIdWanted() would turn it to > > on. I agree that it's not ideal but you have a way to know. We could document > > that auto means that it's set to auto and no one asked to automatically enabled > > it. > > Wow, so the extension changes it? Yes. It seemed better to go this way rather than having a secondary read-only GUC for that. > How do we record the "source" of that > change? Do we have other GUCs that do that? No, we don't. But I don't know what exactly you would like to have as a source? What if you have for instance pg_stat_statements, pg_stat_kcache, pg_store_plans and pg_wait_sampling installed? All those extensions need a query_id (or at least benefit from it for pg_wait_sampling), is there any value to give a full list of all the modules that would enable compute_query_id? I'm assuming that anyone wanting to install any of those extensions (or any similar one) is fully aware that they aggregate metrics based on at least a query_id. If they don't, well they probably never read any documentation since postgres 9.2 which introduced query normalization, and I doubt that they will be interested in having access to the information anyway.
В списке pgsql-hackers по дате отправления: