Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)
От | Julien Rouhaud |
---|---|
Тема | Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto) |
Дата | |
Msg-id | 20220218093856.zenl2axicm5mmdc5@jrouhaud обсуждение исходный текст |
Ответ на | Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto) (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)
Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto) |
Список | pgsql-hackers |
Hi, On Fri, Feb 18, 2022 at 05:22:36PM +0900, Michael Paquier wrote: > > So, I have been looking at this problem, and I don't see a problem in > doing something like the attached, where we add a "regress" mode to > compute_query_id that is a synonym of "auto". Or, in short, we have > the default of letting a module decide if a query ID can be computed > or not, at the exception that we hide its result in EXPLAIN outputs. > > Julien, what do you think? I don't see any problem with that patch. > > FWIW, about your question of upthread, I have noticed the behavior > while testing, but I know of some internal customers that enable > pg_stat_statements and like doing tests on the PostgreSQL instance > deployed this way, so that would break. They are not on 14 yet as far > as I know. Are they really testing EXPLAIN output, or just doing application-level tests?
В списке pgsql-hackers по дате отправления: