Re: [PATCH] pg_stat_toast

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] pg_stat_toast
Дата
Msg-id CA+TgmoZoY6oUZzOc-mGEO-Ti-3G4DkrPCkeLzSXkpKhMXqqZ7w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] pg_stat_toast  (Andres Freund <andres@anarazel.de>)
Ответы Re: [PATCH] pg_stat_toast  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: [PATCH] pg_stat_toast  ("Gunnar \"Nick\" Bluth" <gunnar.bluth@pro-open.de>)
Список pgsql-hackers
On Tue, Apr 5, 2022 at 10:34 PM Andres Freund <andres@anarazel.de> wrote:
> > Anyway, my (undisputed up to now!) understanding still is that only
> > backends _looking_ at these stats (so, e.g., accessing the pg_stat_toast
> > view) actually read the data. So, the 10-15% more space used for pg_stat
> > only affect the stats collector and _some few_ backends.
>
> It's not so simple. That stats collector constantly writes these stats out to
> disk. And disk bandwidth / space is of course a shared resource.

Yeah, and just to make it clear, this really becomes an issue if you
have hundreds of thousands or even millions of tables. It's a lot of
extra data to be writing, and in some cases we're rewriting it all,
like, once per second.

Now if we're only incurring that overhead when this feature is
enabled, then in fairness that problem is a lot less of an issue,
especially if this is also disabled by default. People who want the
data can get it and pay the cost, and others aren't much impacted.
However, experience has taught me that a lot of skepticism is
warranted when it comes to claims about how cheap extensions to the
statistics system will be.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: SQL/JSON: JSON_TABLE
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Practical Timing Side Channel Attacks on Memory Compression