Re: Proposal: roll pg_stat_statements into core

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Euler Taveira <euler(at)timbira(dot)com(dot)br>
Cc: Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: roll pg_stat_statements into core
Date: 2019-09-02 16:07:17
Message-ID: 28432.1567440437@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Euler Taveira <euler(at)timbira(dot)com(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chapman Flack 2019-09-02 16:57:31 Re: safe to overload objectSubId for a type?
Previous Message Alvaro Herrera 2019-09-02 16:00:25 Re: [PATCH] Implement uuid_version()