Andy Fan <zhihuifan1213@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
