Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower.
От | David Gould |
---|---|
Тема | Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower. |
Дата | |
Msg-id | 20160319012009.19ca590d@engels обсуждение исходный текст |
Ответ на | Re: BUG #13750: Autovacuum slows down with large numbers of tables. More workers makes it slower. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: