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

On 3/16/19 5:32 PM, Robert Haas wrote:

> There's only one query ID field available, and
> you can't use two extensions that care about query ID unless they
> compute it the same way, and replicating all the code that computes
> the query ID into each new extension that wants one sucks. I think we
> should actually bite the bullet and move all of that code into core,
> and then just let extensions say whether they care about it getting
> set.

+1.

But I think that enough to integrate into core the query normalization
routine and store generalized query strings (from which the queryId is
produced) in shared memory (for example, hashtable that maps queryId to
the text representation of generalized query). And activate
normalization routine and filling the table of generalized queries by
specified GUC.

This allows to unbind extensions that require queryId from using
pg_stat_statements and consider such computing of queryId as canonical.

--
Regards,
Maksim Milyutin