On Mon, Jun 3, 2024 at 7:11 AM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote: > The main argument is that we currently don’t have writes counters for > relations. > The reason is that we don’t have the relation OID when writing buffers out.
OK. > Second argument is that this is also beneficial for the "Split index and > table statistics into different types of stats" thread (mentioned in the > previous > message). It would allow us to avoid additional branches in some situations > (like > the one mentioned by Andres in the link I provided up-thread). OK. > 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 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. -- Robert Haas EDB: http://www.enterprisedb.com
