Re: Proposal: roll pg_stat_statements into core

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
>

In response to

Browse pgsql-hackers by date

  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