Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Thu, Mar 18, 2021 at 07:29:56AM +0800, Julien Rouhaud wrote:
> On Wed, Mar 17, 2021 at 06:32:16PM -0400, Bruce Momjian wrote:
> > OK, is that what everyone wants?  I think that is what the patch already
> > does.
> 
> Note exactly.  Right now a custom queryid can be computed even if
> compute_queryid is off, if some extension does that in post_parse_analyze_hook.
> 
> I'm assuming that what Robert was thinking was more like:
> 
> if (compute_queryid)
> {
>     if (queryid_hook)
>         queryId = queryid_hook(...);
>     else
>         queryId = JumbeQuery(...);
> }
> else
>     queryId = 0;
> 
> And that should be done *after* post_parse_analyse_hook so that it's clear that
> this hook is no longer the place to compute queryid.
> 
> Is that what should be done?

No, I don't think so.  I think having extensions change behavior
controlled by GUCs is a bad interface.

The docs are going to say that you have to enable compute_queryid to see
the query id in pg_stat_activity and log_line_prefix, but if you install
an extension, the query id will be visible even if you don't have
compute_queryid enabled.  I think you need to only honor the hook if
compute_queryid is enabled, and update the pg_stat_statements docs to
say you have to enable compute_queryid for pg_stat_statements to work.

Also, should it be compute_queryid or compute_query_id?

Also, the overhead of computing the query id was reported as 2% --- that
seems quite high for what it does.  Do we know why it is so high?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.