Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?
От | Hannu Krosing |
---|---|
Тема | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? |
Дата | |
Msg-id | CAMT0RQR10q0RJNHARtzPr-S_dDAX8us1zcbiQBx8YuuRAeYXAg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
It would be really convenient if user-visible serialisations of the query id had something that identifies the computation method.
maybe prefix 'N' for internal, 'S' for pg_stat_statements etc.
This would immediately show in logs at what point the id calculator was changed
maybe prefix 'N' for internal, 'S' for pg_stat_statements etc.
This would immediately show in logs at what point the id calculator was changed
On Fri, Mar 19, 2021 at 5:54 PM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, Mar 19, 2021 at 10:27:51PM +0800, Julien Rouhaud wrote:
> On Fri, Mar 19, 2021 at 09:29:06AM -0400, Bruce Momjian wrote:
> > OK, that makes perfect sense. I think the best solution is to document
> > that compute_query_id just controls the built-in computation of the
> > query id, and that extensions can also compute it if this is off, and
> > pg_stat_activity and log_line_prefix will display built-in or extension
> > computed query ids.
>
> So the last version of the patch should implement that behavior right? It's
> just missing some explicit guidance that third-party extensions should only
> calculate a queryid if compute_query_id is off
Yes, I think we are now down to just how the extensions should be told
to behave, and how we document this --- see the email I just sent.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
В списке pgsql-hackers по дате отправления: