On Thu, Mar 18, 2021 at 03:23:49PM -0400, Bruce Momjian wrote:
> On Fri, Mar 19, 2021 at 02:06:56AM +0800, Julien Rouhaud wrote:
>
> The above text is the part that made me think an extension could display
> a query id even if disabled by the GUC.
With the last version of the patch I sent it was the case.
> Oh, OK. I can see an extension setting the query id on its own --- we
> can't prevent that from happening. It is probably enough to tell
> extensions to honor the GUC, since they would want it enabled so it
> displays in pg_stat_activity and log_line_prefix.
Ok. So no new hook, and we keep using post_parse_analyze_hook as the official
way to have custom queryid implementation, with this new behavior:
> > - if some extension calculates a queryid during post_parse_analyze_hook, we
> > will always reset it.
>
> OK, good.
Now that I'm back on the code I remember why I did it this way. It's
unfortunately not really possible to make things work this way.
pg_stat_statements' post_parse_analyze_hook relies on a queryid already being
computed, as it's where we know where the constants are recorded. It means:
- we have to call post_parse_analyze_hook *after* doing core queryid
calculation
- if users want to use a third party module to calculate a queryid, they'll
have to make sure that the module's post_parse_analyze_hook is called
*before* pg_stat_statements' one.
- even if they do so, they'll still have to pay the price of core queryid
calculation
So it would be very hard to configure and will be too expensive. I think that
we have to choose to either we make compute_query_id only trigger core
calculation (like it was in previous patch version), or introduce a new hook.
> I think compute_query_id works, and is shorter.
WFM.
> OK, good to know. I can run some tests here if people would like me to.
+1. A read only pgbench will be some kind od worse case scenario that can be
used I think.
