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.
