From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: roll pg_stat_statements into core |
Date: | 2019-09-01 18:58:38 |
Message-ID: | CAFj8pRBT6rGbCvv7AnH3zrpcvNT7mBeNWPzaGH3A9z=9JZzsgw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
ne 1. 9. 2019 v 20:48 odesílatel David Fetter <david(at)fetter(dot)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(at)fetter(dot)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"
>
> 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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-09-01 20:50:00 | Re: REL_12_STABLE crashing with assertion failure in ExtractReplicaIdentity |
Previous Message | Tom Lane | 2019-09-01 18:54:34 | Re: Proposal: roll pg_stat_statements into core |