Re: [PATCH] pg_stat_toast - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [PATCH] pg_stat_toast
Date
Msg-id CA+TgmoZoY6oUZzOc-mGEO-Ti-3G4DkrPCkeLzSXkpKhMXqqZ7w@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] pg_stat_toast  (Andres Freund <andres@anarazel.de>)
Responses 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>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: Re: SQL/JSON: JSON_TABLE
Next
From: Greg Stark
Date:
Subject: Re: Practical Timing Side Channel Attacks on Memory Compression