Re: Proposal: roll pg_stat_statements into core
От | Stephen Frost |
---|---|
Тема | Re: Proposal: roll pg_stat_statements into core |
Дата | |
Msg-id | CAOuzzgoCeF7pzWd+idNwCDQX5KjJEeOppjDjGcaQihFSJ12RNw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: roll pg_stat_statements into core (David Fetter <david@fetter.org>) |
Список | pgsql-hackers |
Greetings,
On Tue, Sep 3, 2019 at 19:38 David Fetter <david@fetter.org> wrote:
On Tue, Sep 03, 2019 at 03:56:28PM -0400, Stephen Frost wrote:
> Greetings,
>
> * David Fetter (david@fetter.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
В списке pgsql-hackers по дате отправления: