Hi,
On 2022-12-11 20:48:15 -0500, Tom Lane wrote:
> 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.
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