Re: 9.3 feature proposal: vacuumdb -j #
| От | Andrew Dunstan |
|---|---|
| Тема | Re: 9.3 feature proposal: vacuumdb -j # |
| Дата | |
| Msg-id | 4F161F6B.9020808@dunslane.net обсуждение исходный текст |
| Ответ на | Re: 9.3 feature proposal: vacuumdb -j # (Jim Nasby <jim@nasby.net>) |
| Список | pgsql-hackers |
On 01/17/2012 07:09 PM, Jim Nasby wrote: > On Jan 13, 2012, at 4:15 PM, Christopher Browne wrote: >> Have two logical tasks: >> a) A process that manages the list, and >> b) Child processes doing vacuums. >> >> Each time a child completes a table, it asks the parent for another one. > There is also a middle ground, because having the the scheduling process sounds like a lot more work than what Josh wasproposing. > > CREATE TEMP SEQUENCE s; > SELECT relname, s mod<number of backends> AS backend_number > FROM ( SELECT relname > FROM pg_class > ORDER BY relpages > ); > > Of course, having an actual scheduling process is most likely the most efficient. We already have a model for this in parallel pg_restore. It would probably not be terribly hard to adapt to parallel vacuum. cheers andrew
В списке pgsql-hackers по дате отправления: