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

From Gunnar \"Nick\" Bluth
Subject Re: [PATCH] pg_stat_toast
Date
Msg-id 42bfa680-7998-e7dc-b50e-480cdd986ffc@pro-open.de
Whole thread Raw
In response to Re: [PATCH] pg_stat_toast  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Am 13.12.21 um 00:41 schrieb Andres Freund:
> Hi,
> 
> On 2021-12-13 00:00:23 +0100, Gunnar "Nick" Bluth wrote:
>> Regarding stats size; it adds one PgStat_BackendToastEntry
>> (PgStat_BackendAttrIdentifier + PgStat_ToastCounts, should be 56-64 bytes or
>> something in that ballpark) per TOASTable attribute, I can't see that make
>> any system break sweat ;-)
> 
> That's actually a lot. The problem is that all the stats data for a database
> is loaded into private memory for each connection to that database, and that
> the stats collector regularly writes out all the stats data for a database.

My understanding is that the stats file is only pulled into the backend 
when the SQL functions (for the view) are used (see 
"pgstat_fetch_stat_toastentry()").

Otherwise, a backend just initializes an empty hash, right?

Of which I reduced the initial size from 512 to 32 for the below tests 
(I guess the "truth" lies somewhere in between here), along with making 
the GUC parameter an actual GUC parameter and disabling the elog() calls 
I scattered all over the place ;-) for the v0.2 patch attached.

>> A quick run comparing 1.000.000 INSERTs (2 TOASTable columns each) with and
>> without "pgstat_track_toast" resulted in 12792.882 ms vs. 12810.557 ms. So
>> at least the call overhead seems to be neglectible.
> 
> Yea, you'd probably need a few more tables and a few more connections for it
> to have a chance of mattering meaningfully.

So, I went ahead and
* set up 2 clusters with "track_toast" off and on resp.
* created 100 DBs
  * each with 100 tables
  * with one TOASTable column in each table
  * filling those with 32000 bytes of md5 garbage

These clusters sum up to ~ 2GB each, so differences should _start to_ 
show up, I reckon.

$ du -s testdb*
2161208 testdb
2163240 testdb_tracking

$ du -s testdb*/pg_stat
4448    testdb/pg_stat
4856    testdb_tracking/pg_stat

The db_*.stat files are 42839 vs. 48767 bytes each (so confirmed, the 
differences do show).


No idea if this is telling us anything, tbth, but the 
/proc/<pid>/smaps_rollup for a backend serving one of these DBs look 
like this ("0 kB" lines omitted):

track_toast OFF
===============
Rss:               12428 kB
Pss:                5122 kB
Pss_Anon:           1310 kB
Pss_File:           2014 kB
Pss_Shmem:          1797 kB
Shared_Clean:       5864 kB
Shared_Dirty:       3500 kB
Private_Clean:      1088 kB
Private_Dirty:      1976 kB
Referenced:        11696 kB
Anonymous:          2120 kB

track_toast ON (view not called yet):
=====================================
Rss:               12300 kB
Pss:                4883 kB
Pss_Anon:           1309 kB
Pss_File:           1888 kB
Pss_Shmem:          1685 kB
Shared_Clean:       6040 kB
Shared_Dirty:       3468 kB
Private_Clean:       896 kB
Private_Dirty:      1896 kB
Referenced:        11572 kB
Anonymous:          2116 kB

track_toast ON (view called):
=============================
Rss:               15408 kB
Pss:                7482 kB
Pss_Anon:           2083 kB
Pss_File:           2572 kB
Pss_Shmem:          2826 kB
Shared_Clean:       6616 kB
Shared_Dirty:       3532 kB
Private_Clean:      1472 kB
Private_Dirty:      3788 kB
Referenced:        14704 kB
Anonymous:          2884 kB

That backend used some memory for displaying the result too, of course...

A backend with just two TOAST columns in one table (filled with 
1.000.001 rows) looks like this before and after calling the 
"pg_stat_toast" view:
Rss:              146208 kB
Pss:              116181 kB
Pss_Anon:           2050 kB
Pss_File:           2787 kB
Pss_Shmem:        111342 kB
Shared_Clean:       6636 kB
Shared_Dirty:      45928 kB
Private_Clean:      1664 kB
Private_Dirty:     91980 kB
Referenced:       145532 kB
Anonymous:          2844 kB

Rss:              147736 kB
Pss:              103296 kB
Pss_Anon:           2430 kB
Pss_File:           3147 kB
Pss_Shmem:         97718 kB
Shared_Clean:       6992 kB
Shared_Dirty:      74056 kB
Private_Clean:      1984 kB
Private_Dirty:     64704 kB
Referenced:       147092 kB
Anonymous:          3224 kB

After creating 10.000 more tables (view shows 10.007 rows now), before 
and after calling "TABLE pg_stat_toast":
Rss:               13816 kB
Pss:                4898 kB
Pss_Anon:           1314 kB
Pss_File:           1755 kB
Pss_Shmem:          1829 kB
Shared_Clean:       5972 kB
Shared_Dirty:       5760 kB
Private_Clean:       832 kB
Private_Dirty:      1252 kB
Referenced:        13088 kB
Anonymous:          2124 kB

Rss:              126816 kB
Pss:               55213 kB
Pss_Anon:           5383 kB
Pss_File:           2615 kB
Pss_Shmem:         47215 kB
Shared_Clean:       6460 kB
Shared_Dirty:     113028 kB
Private_Clean:      1600 kB
Private_Dirty:      5728 kB
Referenced:       126112 kB
Anonymous:          6184 kB


That DB's stat-file is now 4.119.254 bytes (3.547.439 without track_toast).

After VACUUM ANALYZE, the size goes up to 5.919.812 (5.348.768).
The "100 tables" DBs' go to 97.910 (91.868) bytes.

In total:
$ du -s testdb*/pg_stat
14508   testdb/pg_stat
15472   testdb_tracking/pg_stat


IMHO, this would be ok to at least enable temporarily (e.g. to find out 
if MAIN or EXTERNAL storage/LZ4 compression would be ok/better for some 
columns).

All the 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
Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: using extended statistics to improve join estimates
Next
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side