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

From Gunnar \"Nick\" Bluth
Subject Re: [PATCH] pg_stat_toast
Date
Msg-id ffca1481-72e7-f88b-cc3f-0969d61e21bf@pro-open.de
Whole thread Raw
In response to Re: [PATCH] pg_stat_toast  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Am 06.04.22 um 17:49 schrieb Alvaro Herrera:
> On 2022-Apr-06, Robert Haas wrote:
> 
>> 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.
> 
> Maybe this feature should provide a way to be enabled for tables
> individually, so you pay the overhead only where you need it and don't
> swamp the system with stats for uninteresting tables.
> 
That would obviously be very nice (and Georgios pushed heavily in that
direction ;-).

However, I intentionally bound those stats to the database level (see my
very first mail).

The changes to get them bound to attributes (or tables) would have
required mangling with quite a lot of very elemental stuff, (e.g.
attribute stats only get refreshed by ANALYZE and their structure would
have to be changed significantly, bloating them even if the feature is
inactive).

It also would have made the stats updates synchronous (at TX end), would
have been "blind" for all TOAST efforts done by rolled back TXs etc.

What you can do is of course (just like track_functions):
  ALTER DATABASE under_surveillance SET track_toast = [on|off];

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: Andres Freund
Date:
Subject: Re: Skip partition tuple routing with constant partition key
Next
From: Thomas Munro
Date:
Subject: Re: WIP: WAL prefetch (another approach)