Re: Proposal: roll pg_stat_statements into core
| От | Pavel Stehule |
|---|---|
| Тема | Re: Proposal: roll pg_stat_statements into core |
| Дата | |
| Msg-id | CAFj8pRBh0B9jukO9A6quZSgEzmUmn1MRFLRwPw13OsjOeh+wsw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Proposal: roll pg_stat_statements into core (David Fetter <david@fetter.org>) |
| Ответы |
Re: Proposal: roll pg_stat_statements into core
|
| Список | pgsql-hackers |
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
2. there are not any numbers what is a overhead
Maybe better solution can be some new API for shared memory, that doesn't need to use shared_preload_library.
It can be useful for lot of other monitoring extensions, profilers, debuggers,
Regards
Pavel
Before I go do the patch, I'd like to see whether there's anything
like a consensus as to the what and how of doing this.
What say?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
В списке pgsql-hackers по дате отправления: