Re: compute_query_id and pg_stat_statements

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: compute_query_id and pg_stat_statements
Дата
Msg-id 2295572.1619461260@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: compute_query_id and pg_stat_statements  (Andres Freund <andres@anarazel.de>)
Ответы Re: compute_query_id and pg_stat_statements
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> I think that's the right direction. I wonder though if we shouldn't go a
> bit further. Have one guc that determines the "query id provider" (NULL
> or a shared library), and one GUC that configures whether query-id is
> computed (never, on-demand/auto, always). For the provider GUC load the
> .so and look up a function with some well known name.

That's sounding like a pretty sane design, actually.  Not sure about
the shared-library-name-with-fixed-function-name detail, but certainly
it seems to be useful to separate "I need a query-id" from the details
of the ID calculation.

Rather than a GUC per se for the ID provider, maybe we could have a
function hook that defaults to pointing at the in-core computation,
and then a module wanting to override that just gets into the hook.

            regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: compute_query_id and pg_stat_statements
Следующее
От: Andres Freund
Дата:
Сообщение: Re: compute_query_id and pg_stat_statements