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

From Gunnar \"Nick\" Bluth
Subject Re: [PATCH] pg_stat_toast
Date
Msg-id cc361462-c44b-2a3d-e48b-19744b4c4a1c@pro-open.de
Whole thread Raw
In response to Re: [PATCH] pg_stat_toast  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] pg_stat_toast  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Am 06.04.22 um 17:22 schrieb Robert Haas:
> 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.

Fair enough. At that point, a lot of things become unexpectedly painful.
How many % of the installed base may that be though?

I'm far from done reading the patch and mail thread Andres mentioned,
but I think the general idea is to move the stats to shared memory, so
that reading (and thus, persisting) pg_stats is required far less often,
right?

> 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.

That's the idea, yes. I reckon folks with millions of tables will scan
through the docs (and postgresql.conf) very thoroughly anyway. Hence the
note there.

> 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.

Again, fair enough!
Maybe we first need statistics about statistics collection and handling? ;-)

Best,
-- 
Gunnar "Nick" Bluth

Eimermacherweg 106
D-48159 Münster

Mobil +49 172 8853339
Email: gunnar.bluth@pro-open.de
__________________________________________________________________________
"Ceterum censeo SystemD esse delendam" - Cato



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Last day of commitfest
Next
From: Tom Lane
Date:
Subject: Re: Last day of commitfest