Re: Proposal: roll pg_stat_statements into core - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal: roll pg_stat_statements into core
Date
Msg-id 28432.1567440437@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal: roll pg_stat_statements into core  (Euler Taveira <euler@timbira.com.br>)
Responses Re: Proposal: roll pg_stat_statements into core
Re: Proposal: roll pg_stat_statements into core
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] Implement uuid_version()
Next
From: Chapman Flack
Date:
Subject: Re: safe to overload objectSubId for a type?