Re: autovacuum prioritization - Mailing list pgsql-hackers

From Robert Haas
Subject Re: autovacuum prioritization
Date
Msg-id CA+TgmoZMZ+wv0htvkCKa7cDrXqYwMzH8usd3=O6+fL1WvOXA2A@mail.gmail.com
Whole thread Raw
In response to Re: autovacuum prioritization  (John Naylor <john.naylor@enterprisedb.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: autovacuum prioritization
Next
From: Robert Haas
Date:
Subject: Re: Refactoring of compression options in pg_basebackup