| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
| Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us> |
| Subject: | Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto) |
| Date: | 2022-02-18 08:22:36 |
| Message-ID: | Yg9XTF5urx+GzMpL@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 08, 2022 at 12:56:59PM +0900, Michael Paquier wrote:
> Well, I can see that this is a second independent complain after a few
> months. If you wish to keep this capability, wouldn't it be better to
> add a "regress" mode to compute_query_id, where we would mask
> automatically this information in the output of EXPLAIN but still run
> the computation?
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?
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.
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| stat-statements-regress.patch | text/x-diff | 3.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2022-02-18 08:26:04 | Re: Design of pg_stat_subscription_workers vs pgstats |
| Previous Message | Ajin Cherian | 2022-02-18 08:21:49 | Re: logical replication empty transactions |