On Fri, Mar 15, 2019 at 9:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yun Li <liyunjuanyong@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
