Re: Proposal: roll pg_stat_statements into core

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Proposal: roll pg_stat_statements into core
Дата
Msg-id 28432.1567440437@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Proposal: roll pg_stat_statements into core  (Euler Taveira <euler@timbira.com.br>)
Ответы Re: Proposal: roll pg_stat_statements into core  (Michael Paquier <michael@paquier.xyz>)
Re: Proposal: roll pg_stat_statements into core  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Euler Taveira <euler@timbira.com.br> writes:
> At least if pg_stat_statements
> was in core you could load it by default and have a GUC to turn it
> on/off without restarting the server (that was Magnus proposal and
> Andres agreed).

That assertion is 100% bogus.  To turn it on or off on-the-fly,
you'd need some way to acquire or release its shared memory
on-the-fly.

It's probably now possible to do something like that, using the
DSM mechanisms, but the code for it hasn't been written (AFAIK).
And it wouldn't have much to do with whether the module was
in core or stayed where it is.

Another concern that I have about moving pg_stat_statements
into core is that doing so would effectively nail down
Query.queryId as belonging to pg_stat_statements, whereas
currently it's possible for other plugins to commandeer that
if they wish.  This isn't academic, because of the fact that
not everybody is satisfied with the way pg_stat_statements
defines queryId [1].

            regards, tom lane

[1] https://www.postgresql.org/message-id/flat/1553029215728-0.post%40n3.nabble.com



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PATCH] Implement uuid_version()
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: safe to overload objectSubId for a type?