| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
| Cc: | David Gould <daveg(at)sonic(dot)net>, 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 13:39:34 |
| Message-ID: | 16126.1458308374@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> I actually wonder if instead of doing all the the hard way in C whether
> we should just use SPI for each worker to build it's list of tables. The
> big advantage that would provide is the ability for users to customize
> the scheduling, but I suspect it'd make the code simpler too.
By that you mean "user can write a SQL query that determines autovacuum
targets"? -1. That would bring us back to the bad old days where a
poorly-thought-out vacuum cron job would miss tables and lead to a
database shutdown. Not to mention SQL injection risks.
If we need to improve autovac's strategy, let's do that, but not by
deeming it the user's problem.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bronislav.Houdek | 2016-03-18 14:09:37 | BUG #14034: Select for update with inner select doesn't return value after committing by other transaction. |
| Previous Message | Tom Lane | 2016-03-18 13:25:31 | Re: Incorrect accounting (n_tup_ins) of non-inserted rows |