ne 1. 9. 2019 v 20:48 odesílatel David Fetter <david@fetter.org> napsal:
On Sun, Sep 01, 2019 at 08:12:15PM +0200, Pavel Stehule wrote: > Hi > > ne 1. 9. 2019 v 20:00 odesílatel David Fetter <david@fetter.org> napsal: > > > Folks, > > > > I'd like to $Subject, on by default, with a switch to turn it off for > > those really at the outer edges of performance. Some reasons include: > > > > - It's broadly useful. > > - 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. > > - The overhead for most use cases is low compared to the benefit. > > > > I have not a strong opinion about it. pg_stat_statements is really useful > extenstion, on second hand > > 1. the API is not stabilized yet - there are some patches related to this > extension if I remember correctly
You do.
> 2. there are not any numbers what is a overhead
What numbers would you suggest collecting? We could get some by running them with the extension loaded and not, although this goes to your next proposal.
I would to see some benchmarks (pg_bench - readonly, higher number of connects)
> Maybe better solution can be some new API for shared memory, that doesn't > need to use shared_preload_library.
What would such an API look like?
possibility to allocate shared large blocks of shared memory without necessity to do it at startup time
> It can be useful for lot of other monitoring extensions, profilers, > debuggers,
It would indeed.
Do you see this new API as a separate project, and if so, of approximately what size? Are we talking about something about the size of DSM? Of JIT?
Probably about DSM, and about API how to other processes can connect to some blocks of DSM. I rember similar request related to shared fulltext dictionaries
It can be part of some project "enhancing pg_stat_statement - be possible load this extension without restart"