Andy Fan <zhihuifan1...@163.com> writes: > >> - Longrunning transaction prevents increasing relfrozenxid, we run autovacuum >> over and over on the same relation, using up the whole cost budget. This is >> particularly bad because often we'll not autovacuum anything else, building >> up a larger and larger backlog of actual work. > > Could we maintain a pg_class.last_autovacuum_min_xid during vacuum? So > if we compare the OldestXminXid with pg_class.last_autovacuum_min_xid > before doing the real work.
Maintaining the oldestXminXid on this relation might be expensive. >> >> - Tables, where on-access pruning works very well, end up being vacuumed far >> too frequently, because our autovacuum scheduling doesn't know about tuples >> having been cleaned up by on-access pruning. > > Good to know this case. if we update the pg_stats_xx metrics when on-access > pruning, would it is helpful on this? I got the answer myself, it doesn't work because on-access pruing working on per-index level and one relation may has many indexes. and pg_stats_xx works at relation level. So the above proposal doesn't work. -- Best Regards Andy Fan
