Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower. - Mailing list pgsql-bugs

From David Gould
Subject Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower.
Date
Msg-id 20160319012009.19ca590d@engels
Whole thread Raw
In response to Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Fri, 18 Mar 2016 18:23:51 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> David Gould <daveg@sonic.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@sonic.net
If simplicity worked, the world would be overrun with insects.

pgsql-bugs by date:

Previous
From: David Gould
Date:
Subject: Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower.
Next
From: Ilya Matveychikov
Date:
Subject: Re: BUG #14027: n_tup_ins increments regardless of insertion success