Re: cost delay brainstorming

Andy Fan <zhihuifan1213(at)163(dot)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