Michael Paquier <mich...@paquier.xyz> writes: > On Sun, Dec 11, 2022 at 04:51:49PM -0800, Andres Freund wrote: >> I think there's a good argument for starting to track some stats based on the >> relfilenode, rather the oid, because it'd allow us to track e.g. the number >> of >> writes for a relation too (we don't have the oid when writing out >> buffers). But that's a relatively large change...
> Yeah. I was thinking among the lines of sync requests and sync > failures, as well. I think a stats table indexed solely by relfilenode wouldn't be a great idea, because you'd lose all the stats about a table as soon as you do vacuum full/cluster/rewriting-alter-table/etc. Can we create two index structures over the same stats table entries, so you can look up by either relfilenode or OID? I'm not quite sure how to manage rewrites, where you transiently have two relfilenodes for "the same" table ... maybe we could allow multiple pointers to the same stats entry?? regards, tom lane