Re: autovacuum prioritization

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: autovacuum prioritization
Дата
Msg-id CA+TgmoZMZ+wv0htvkCKa7cDrXqYwMzH8usd3=O6+fL1WvOXA2A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: autovacuum prioritization  (John Naylor <john.naylor@enterprisedb.com>)
Список pgsql-hackers
On Tue, Jan 25, 2022 at 3:34 PM John Naylor
<john.naylor@enterprisedb.com> wrote:
> I was thinking along the same lines as Dilip: If the anti-wraparound
> risk is really far in the future, there might not be much eligible
> freezing work to do. Dead tuples can be removed as soon as visibility
> rules allow it. With a separate bloat queue, there might always be
> some work to do.

Isn't the same thing true of bloat, though? If the XID threshold
hasn't advanced that much, then there may be nothing that's worth
doing about XID wraparound in the short term. If there aren't many
dead tuples in any of the tables, then there may be nothing that's
worth doing about bloat. Then we should just do nothing. On the other
hand, we may have a relatively urgent problem in one of those areas
but not the other. Then we should work on that one. Or we may have
problems in both areas, and then we need to somehow decide which one
is more urgent -- that's the situation in which I feel like we need to
unify the prioritization or ordering in some way.

It is an interesting point that we could have low priority work with a
low cost limit and high priority work with a higher cost limit, or as
I think Peter suggested, just use a single process for low-priority
stuff but allow multiple processes when there's high-priority stuff.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: autovacuum prioritization
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Refactoring of compression options in pg_basebackup