Re: Proposal: roll pg_stat_statements into core - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Proposal: roll pg_stat_statements into core
Date
Msg-id 20190903195628.GX16436@tamriel.snowman.net
Whole thread Raw
In response to Proposal: roll pg_stat_statements into core  (David Fetter <david@fetter.org>)
Responses Re: Proposal: roll pg_stat_statements into core
Re: Proposal: roll pg_stat_statements into core
List pgsql-hackers
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..)
but we simply haven't got great facilities for either migrating those
things into core (particularly during an upgrade..) or making them
available directly in a way that isn't intrusive (seems like maybe we
should have an independent schema from pg_catalog that's for things like
this...  utility functions and views over them which are particularly
useful; harkins back to the ancient discussion about a new pg_catalog
structure...  pg new sysviews, or something along those lines?).

Figure out how to fix those issues and maybe there's something
interesting to discuss here, until then, a thread like this is likely to
be unproductive.  A direct patch that just shoves pg_stat_statements
into core isn't going to cut it.

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: SIGQUIT on archiver child processes maybe not such a hot idea?
Next
From: Alvaro Herrera
Date:
Subject: Re: [proposal] de-TOAST'ing using a iterator