On Tue, Jan 25, 2022 at 2:30 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Mon, Jan 24, 2022 at 11:14 PM Dilip Kumar <dilipbal...@gmail.com> wrote:
> > I think we need to make different priority > > queues based on different factors, for example 1 queue for wraparound > > risk and another for bloat risk. > > I don't see why we want multiple queues. We have to answer the > question "what should we do next?" which requires us, in some way, to > funnel everything into a single prioritization. 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. Maybe "bloat queue" is too specific, because insert-only tables can use more vacuuming for the VM even if they have not reached the configured threshold. So a worker would check the wraparound queue, and if nothing's there grab something from the other queue. Maybe low-priority work would have a low cost limit. Probably the true best way to do schedule, at least at first, is what's the least complex. I'm not yet sure what that is... -- John Naylor EDB: http://www.enterprisedb.com
