Michael Paquier <michael@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