Horton

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

Maksim Milyutin <milyutinma@gmail.com>

View thread View on postgr.es
From: Maksim Milyutin <milyutinma@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Yun Li <liyunjuanyong@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-19T13:45:17Z
Lists: pgsql-hackers 
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

Commits

  1. Clarify description of pg_stat_statements columns

  2. Fix wording in description of pg_stat_statements.toplevel

  3. Mention that toplevel is part of pg_stat_statements key.

  4. adjust query id feature to use pg_stat_activity.query_id

  5. Update copyright for 2021

  6. Take the statistics collector out of the loop for monitoring backends'