Re: New GUC autovacuum_max_threshold ?

> And as far as that goes, I'd like you - and others - to spell out more
> precisely why you think 100 or 200 million tuples is too much. It
> might be, or maybe it is in some cases but not in others. To me,
> that's not a terribly large amount of data. Unless your tuples are
> very wide, it's a few tens of gigabytes. That is big enough that I can
> believe that you *might* want autovacuum to run when you hit that
> threshold, but it's definitely not *obvious* to me that you want
> autovacuum to run when you hit that threshold.

Vacuuming the heap alone gets faster the more I do it, thanks to the
visibility map. However, the more indexes I have, and the larger ( in the TBs),
the indexes become, autovacuum workers will be
monopolized vacuuming these indexes.

At 500k tuples, I am constantly vacuuming large indexes
and monopolizing autovacuum workers. At 100 or 200
million tuples, I will also monopolize autovacuum workers
as they vacuums indexes for many minutes or hours.

At 100 or 200 million, the monopolization will occur less often,
but it will still occur leading an operator to maybe have to terminate
the autovacuum an kick of a manual vacuum.

I am not convinced a new tuple based threshold will address this,
but I may also may be misunderstanding the intention of this GUC.

> To make that concrete: If the table is 10TB, do you want to vacuum to
> reclaim 20GB of bloat? You might be vacuuming 5TB of indexes to
> reclaim 20GB of heap space - is that the right thing to do? If yes,
> why?

No, I would not want to run autovacuum on 5TB indexes to reclaim
a small amount of bloat.

Regards,

Sami