Re: shared memory stats: high level design decisions: consistency, dropping
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Date: 2021-03-24T08:51:14Z
Lists: pgsql-hackers
On 2021-Mar-21, Andres Freund wrote: > We currently also fetch the full stats in places like autovacuum.c. Where we > don't need repeated access to be consistent - we even explicitly force the > stats to be re-read for every single table that's getting vacuumed. > > Even if we to just cache already accessed stats, places like do_autovacuum() > would end up with a completely unnecessary cache of all tables, blowing up > memory usage by a large amount on systems with lots of relations. It's certainly not the case that autovacuum needs to keep fully consistent stats. That's just the way that seemed easier (?) to do at the time. Unless I misunderstand things severely, we could just have autovacuum grab all necessary numbers for one database at the start of a run, not cache anything, then re-read the numbers for one table as it rechecks that table. Resetting before re-reading was obviously necessary because the built-in snapshotting made it impossible to freshen up the numbers at the recheck step. -- Álvaro Herrera 39°49'30"S 73°17'W
Commits
-
pgstat: store statistics in shared memory.
- 5891c7a8ed8f 15.0 landed