On Fri, Mar 15, 2019 at 9:50 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Yun Li <liyunjuany...@gmail.com> writes: > > Do you think if we can add queryId into the pg_stat_get_activity function > > and ultimatly expose it in the view? It would be easier to track "similar" > > query's performance over time easier. > > No, we're not likely to do that, because it would mean (1) baking one > single definition of "query ID" into the core system and (2) paying > the cost to calculate that ID all the time. > > pg_stat_statements has a notion of query ID, but that notion might be > quite inappropriate for other usages, which is why it's an extension > and not core.
Having written an extension that also wanted a query ID, I disagree with this position. 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. Also, I think this is now the third independent request to expose query ID in pg_stat_statements. I think we should give the people what they want. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company