Hi, On 2022-12-11 20:48:15 -0500, Tom Lane wrote: > 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.
I don't think that'd be a huge issue - we already have code to keep some stats as part of rewrites that change the oid of a relation. We could do the same for rewrites that just change the relfilenode. However, I'm not sure it's a good idea to keep the stats during rewrites. Most rewrites end up not copying dead tuples, for example, so keeping the old counts of updated tuples doesn't really make sense. > Can we create two index structures over the same stats table entries, > so you can look up by either relfilenode or OID? We could likely do that, yes. I think we'd have one "stats body" and multiple hash table entries pointing to one. The complicated bit would likely be that we'd need some additional refcounting to know when there's no references to the "stats body" left. Greetings, Andres Freund
