From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
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-03 23:41:00 |
Message-ID: | CAOuzzgoCeF7pzWd+idNwCDQX5KjJEeOppjDjGcaQihFSJ12RNw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
On Tue, Sep 3, 2019 at 19:38 David Fetter <david(at)fetter(dot)org> wrote:
> On Tue, Sep 03, 2019 at 03:56:28PM -0400, Stephen Frost wrote:
> > Greetings,
> >
> > * David Fetter (david(at)fetter(dot)org) wrote:
> > > 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:
> >
> > Sure, half of contrib should really be in core (amcheck, file_fdw,
> > postgres_fdw, maybe dblink, pageinspect, pg_buffercache,
> > pg_freespacemap, pgstattuple, pg_visibility, sslinfo, maybe pgtrgm..)
>
> Agreed.
>
> > but we simply haven't got great facilities for either migrating those
> > things into core (particularly during an upgrade..)
>
> So a process that makes transitioning from extension to core in a(n at
> least largely) mechanical way sounds like a Useful Thing™.
>
> Would that be worth a separate thread once this CF is over?
A well considered proposal might be interesting. A “call to arms” asking
someone to create same likely wouldn’t be.
Thanks,
Stephen
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2019-09-03 23:44:46 | Re: Proposal: roll pg_stat_statements into core |
Previous Message | David Fetter | 2019-09-03 23:38:40 | Re: Proposal: roll pg_stat_statements into core |