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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Gould <daveg(at)sonic(dot)net>
Cc: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower.
Date: 2016-03-18 22:23:51
Message-ID: 13348.1458339831@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Artur Zakirov 2016-03-18 22:37:03 Re: BUG #14032: trigram index is not used for '=' operator
Previous Message Tomas Vondra 2016-03-18 22:17:25 Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower.