Hi,
On 2024-12-27 12:32:25 +0900, Michael Paquier wrote:
> While brainstorming on the contents of the thread I have posted a
> couple of days ago, I have been looking at what could be done so as
> pgstats and WAL-logging could work together. This was point 2) from
> this message:
> https://www.postgresql.org/message-id/z2tblemfuofzy...@paquier.xyz
>
> While considering the point that not all stats data is worth
> replicating, I have fallen down to the following properties that are
> nice to have across the board:
> - A pgstats kind should be able to WAL-log some data that is should be
> able to decide. Including versioning of the data.
I don't really think that's right. For cumulative stats to make sense on both
a primary and a replica, or a primary after a crash, they need to cover things
that *already* are WAL logged.
E.g. for pg_stat_all_tables.n_{tup_{ins,upd,del,hot_upd},live_tup,dead_tup,
...}, - which are important for autovacuum scheduling - we should use the WAL
records covering those changes to re-assemble the stats during WAL replay.
The only reason that that's not trivial is that we don't have access to the
relation oid during crash recovery. Which in turn is why I think we should
change relation level stats to be keyed by relfilenode, rather than relation
oid.
I can't think of a real case where we would want to WAL log the stats
themselves, rather than re-emitting stats during replay based on the WAL
record of the "underlying object".
Do you have counter-examples?
Greetings,
Andres Freund
