Hi, On 2019-09-02 12:07:17 -0400, Tom Lane wrote: > Euler Taveira <eu...@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.
Not necessarily - in practice the issue of pg_stat_statements having overhead isn't about the memory overhead, but the CPU overhead. And that we can nearly entirely disable/enable without acquiring / releasing shared memory already, by setting pg_stat_statements.track to NONE. There's still the overhead of being indirected through the pgss_* hooks, which then have to figure out that pgss is disabled. But that's obviously much smaller than the overhead of pgss itself. Although I do wonder if it's time that we make hook registration/unregistration a bit more flexible - it's basically impossible to unregister hooks right now because the chain of hooks is distributed over multiple files. If we instead provided a few helper functions to register hooks we could allow deregistering as well. > 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. I think it'd be good to add DSM support for pg_stat_statements - but as you say that's largely independent of it being mainlined. > 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]. I'm not sure I see this as that big an issue - we could have a few different query ids for each query. If it's a problem that there's potentially different desirable semantics for queryId, then it's also an issue that we can have only one. Greetings, Andres Freund
