Re: Proposal: roll pg_stat_statements into core

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..)
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