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 CAMT0RQTHBU8UaG_u4_uX7EHXeSUs3AvgyS+6wMLwjq=EaB06mw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On Fri, Mar 19, 2021 at 2:29 PM Bruce Momjian <bruce@momjian.us> 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.
>
> It might be interesting someday to check if the hook changed a
> pre-computed query id and warn the user in the logs, but that could
> cause more log-spam problems than help.

The log-spam could be mitigated by logging it just once per connection
the first time it is overridden

Also, we could ask the extensions to expose the "method name" in a read-only GUC

so one can do

SHOW compute_query_id_method;

and get the name of method use

compute_query_id_method
------------------------------------
builtin

And it may even dynamically change to indicate the overriding of builtin

compute_query_id_method
---------------------------------------------------
fancy_compute_query_id (overrides builtin)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: SQL-standard function body
Следующее
От: David Steele
Дата:
Сообщение: Re: fdatasync performance problem with large number of DB files