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
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. |