Re: pg_stat_*_columns?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pg_stat_*_columns?
Дата
Msg-id CA+TgmoYTmtDk8xyhRR5ntz5=577-kSiLpbe_dTXLg3-VVW837Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_stat_*_columns?  (Joel Jacobson <joel@trustly.com>)
Ответы Re: pg_stat_*_columns?
Re: pg_stat_*_columns?
Список pgsql-hackers
On Sat, Jun 20, 2015 at 10:12 AM, Joel Jacobson <joel@trustly.com> wrote:
> Is there any chance the project would accept a patch which adds the
> pg_stat_*_columns-feature without first optimizing the collector?

I doubt it.  It's such a pain point already that massively increasing
the amount of data we need to store does not seem like a good plan.

> I guess it
> primarily depends on how much of the new code that would need to be
> rewritten, if the collector is optimized/rewritten in the future?

I don't think that's really the issue.  It's more that I think it
would be the extra data would be likely to cause real pain for users.

FWIW, I tend to think that the solution here has less to do with
splitting the data up into more files and more to do with rethinking
the format.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Paul Ramsey
Дата:
Сообщение: Extension support for postgres_fdw
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: pretty bad n_distinct estimate, causing HashAgg OOM on TPC-H