Re: Proposal: roll pg_stat_statements into core

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 19:56:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-09-03 20:12:26 Re: [proposal] de-TOAST'ing using a iterator
Previous Message Stephen Frost 2019-09-03 19:48:42 Re: SIGQUIT on archiver child processes maybe not such a hot idea?