From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, 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-23 02:38:28 |
Message-ID: | 20220223023828.GK9008@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 22, 2022 at 11:04:16AM +0900, Michael Paquier wrote:
> On Fri, Feb 18, 2022 at 05:38:56PM +0800, Julien Rouhaud wrote:
> > 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.
> Okay, thanks. I have worked on that today and applied the patch down
While rebasing, I noticed that this patch does part of what I added in another
thread.
https://commitfest.postgresql.org/37/3409/
| explain_regress, explain(MACHINE), and default to explain(BUFFERS)
- if (es->verbose && plannedstmt->queryId != UINT64CONST(0))
+ if (es->verbose && plannedstmt->queryId != UINT64CONST(0) && es->machine)
{
/*
* Output the queryid as an int64 rather than a uint64 so we match
Apparently, I first wrote this two years ago today.
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2022-02-23 02:46:14 | Re: Design of pg_stat_subscription_workers vs pgstats |
Previous Message | Andres Freund | 2022-02-23 02:25:04 | Re: Use generation context to speed up tuplesorts |