Re: Proposal: roll pg_stat_statements into core

On Tue, Sep 3, 2019 at 11:37 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> grOn Mon, Sep 02, 2019 at 12:07:17PM -0400, Tom Lane wrote:
> > 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.
>
> If we were to actually merge the module into core and switch to DSM
> instead of the current fixed amout of shared memory defined at start
> time, then that would be a two-step process: first push the functions
> into code with a GUC_POSTMASTER as currently done, and secondly
> attempt to switch the GUC to be reloadable.
>
> FWIW, I am not sure that we should have the module into core.
> --
> Michael
>

- It's broadly useful.
No doubt it is very useful and most of the customer is using that.

- Right now, the barrier for turning it on is quite high. In addition
to being non-core, which is already a pretty high barrier at a lot
of organizations,it requires a shared_preload_libraries setting,
which is pretty close to untenable in a lot of use cases.

We are thinking to move a module in core just because of
"barrier for turning it on is quite high" which is not a very compelling
reason. I am just thinking
why not have a system which makes that easy instead of adding to core.

--
Ibrar Ahmed