On Tue, Jun 04, 2024 at 09:26:27AM -0400, Robert Haas wrote: > On Mon, Jun 3, 2024 at 7:11 AM Bertrand Drouvot > <bertranddrouvot...@gmail.com> wrote: > > We’d move the current buffer read and buffer hit counters from the relation > > stats > > to the relfilenode stats (while still being able to retrieve them from the > > pg_statio_all_tables/indexes views: see the example for the new > > heap_blks_written > > stat added in the patch). Generally speaking, I think that tracking > > counters at > > a common level (i.e relfilenode level instead of table or index level) is > > beneficial (avoid storing/allocating space for the same counters in multiple > > structs) and sounds more intuitive to me. > > Hmm. So if I CLUSTER or VACUUM FULL the relation, the relfilenode > changes. Does that mean I lose all of those stats? Is that a problem? > Or is it good? Or what?
I think we should keep the stats in the relation during relfilenode changes. As a POC, v1 implemented a way to do so during TRUNCATE (see the changes in table_relation_set_new_filelocator() and in pg_statio_all_tables): as you can see in the example provided up-thread the new heap_blks_written statistic has been preserved during the TRUNCATE. Please note that the v1 POC only takes care of the new heap_blks_written stat and that the logic used in table_relation_set_new_filelocator() would probably need to be applied in rebuild_relation() or such to deal with CLUSTER or VACUUM FULL. For the relation, the new counter "blocks_written" has been added to the PgStat_StatTabEntry struct (it's not needed in the PgStat_TableCounts one as the relfilenode stat takes care of it). It's added in PgStat_StatTabEntry only to copy/preserve the relfilenode stats during rewrite operations and to retrieve the stats in pg_statio_all_tables. Then, if later we split the relation stats to index/table stats, we'd have blocks_written defined in less structs (as compare to doing the split without relfilenode stat in place). As mentioned up-thread, the new logic has been implemented in v1 only for the new blocks_written stat (we'd need to do the same for the existing buffer read / buffer hit if we agree on the approach implemented in v1). > I also thought about the other direction. Suppose I drop the a > relation and create a new one that gets a different relation OID but > the same relfilenode. But I don't think that's a problem: dropping the > relation should forcibly remove the old stats, so there won't be any > conflict in this case. Yeah. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
