Re: Proposal: roll pg_stat_statements into core

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Proposal: roll pg_stat_statements into core
Дата
Msg-id 20190903195628.GX16436@tamriel.snowman.net
обсуждение исходный текст
Ответ на Proposal: roll pg_stat_statements into core  (David Fetter <david@fetter.org>)
Ответы Re: Proposal: roll pg_stat_statements into core  (David Fetter <david@fetter.org>)
Re: Proposal: roll pg_stat_statements into core  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: SIGQUIT on archiver child processes maybe not such a hot idea?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [proposal] de-TOAST'ing using a iterator