Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower.

On Fri, 18 Mar 2016 18:23:51 -0400
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> David Gould <daveg(at)sonic(dot)net> writes:
> > I have some thoughts for a different approach. In short, the stats collector
> > actually knows what needs vacuuming because queries that create dead tuples
> > tell it. I'm considering have the stats collector maintain a queue of
> > vacuum work and that autovacuum request work from the stats collector. When I
> > have something more concrete I'll post it on hackers.
>
> Uh, what? The autovacuum code already looks at the stats maintained by
> the collector. If what you said means anything, it means "let's move the
> autovac scheduling logic into the collector", which seems neither useful
> nor sound from a modularity standpoint.

Well, there is that. Thats why I'm still considering and not yet posting a
concrete proposal on hackers. Really, there is no convenient location for this
decision making as no single process has all the information needed to
optimize autovacuum scheduling across databases. It's a bit of a puzzle.

-dg

--
David Gould 510 282 0869 daveg(at)sonic(dot)net
If simplicity worked, the world would be overrun with insects.