Re: another autovacuum scheduling thread - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: another autovacuum scheduling thread
Date
Msg-id CAA5RZ0vSPqd5vP4-17E6QELRgQzaoKChgp5TDPK9GhZEK=0Gjg@mail.gmail.com
Whole thread Raw
In response to Re: another autovacuum scheduling thread  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: another autovacuum scheduling thread
List pgsql-hackers
> > I think the one I proposed in [1] does this quite well. The table
> > remains eligible to be autovacuumed with any score >= 1.0, and there's
> > still a huge window of time to freeze a table once it's over
> > autovacuum_freeze_max_age before there are issues and the exponential
> > scaling once over failsafe age should ensure that the table is top of
> > the list for when the failsafe code kicks in and removes the cost
> > limit.
>
> Yeah.  I'll update the patch with that formula.

I was looking at v3, and I understand the formula will be updated in the
next version. However, do you think we should benchmark the approach
of using an intermediary list to store the eligible tables and sorting
that list,
which may cause larger performance overhead for databases with hundreds
of tables that may all be eligible for autovacuum. I do think such cases
out there are common, particularly in multi-tenant type databases, where
each tenant could be one or more tables.

What do you think?

--
Sami



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: C11: should we use char32_t for unicode code points?
Next
From: David Rowley
Date:
Subject: Re: pgsql: Use CompactAttribute more often, when possible