Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?

Поиск
Список
Период
Сортировка
От Maksim Milyutin
Тема Re: Feature improvement: can we add queryId forpg_catalog.pg_stat_activity view?
Дата
Msg-id e26f1ee3-ff22-f871-2348-b04dbc98ec3e@gmail.com
обсуждение исходный текст
Ответ на Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers
On 3/16/19 5:32 PM, Robert Haas wrote:

> 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.


+1.

But I think that enough to integrate into core the query normalization 
routine and store generalized query strings (from which the queryId is 
produced) in shared memory (for example, hashtable that maps queryId to 
the text representation of generalized query). And activate 
normalization routine and filling the table of generalized queries by 
specified GUC.

This allows to unbind extensions that require queryId from using 
pg_stat_statements and consider such computing of queryId as canonical.


-- 
Regards,
Maksim Milyutin



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: partitioned tables referenced by FKs
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: [HACKERS] [PATCH] Generic type subscripting