Re: [PATCH] pg_stat_toast

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Gunnar Nick Bluth <gunnar(dot)bluth(at)pro-open(dot)de>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>
Subject: Re: [PATCH] pg_stat_toast
Date: 2022-04-06 15:22:54
Message-ID: CA+TgmoZoY6oUZzOc-mGEO-Ti-3G4DkrPCkeLzSXkpKhMXqqZ7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 5, 2022 at 10:34 PM Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2022-04-06 15:23:37 Re: Practical Timing Side Channel Attacks on Memory Compression
Previous Message Stephen Frost 2022-04-06 15:11:42 Re: SQL/JSON: JSON_TABLE