Re: Vacuum Full - stops responding(?)
От
Greg Stark
Тема
Re: Vacuum Full - stops responding(?)
Дата
Msg-id
407d949e0910192046r7793e2e1sb53b61cfa60f40db@mail.gmail.com
Ответ на
Re: Vacuum Full - stops responding(?) (Scott Marlowe)
Список
Дерево обсуждения
Vacuum Full - stops responding(?) Krowa Krowax <krowa333@gmail.com>
Re: Vacuum Full - stops responding(?) Tom Lane <tgl@sss.pgh.pa.us>
Re: Vacuum Full - stops responding(?) Scott Marlowe <scott.marlowe@gmail.com>
Re: Vacuum Full - stops responding(?) Greg Stark <gsstark@mit.edu>
Re: Vacuum Full - stops responding(?) Tom Lane <tgl@sss.pgh.pa.us>
Re: Vacuum Full - stops responding(?) Greg Stark <gsstark@mit.edu>
Re: Vacuum Full - stops responding(?) Alvaro Herrera <alvherre@commandprompt.com>
Re: Vacuum Full - stops responding(?) Scott Marlowe <scott.marlowe@gmail.com>
Re: Vacuum Full - stops responding(?) "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
On Mon, Oct 19, 2009 at 7:37 PM, Scott Marlowe wrote: >> It's trying to repack your table in place. On the whole, I'd suggest >> you cancel the vacuum and try a CLUSTER or some such instead. > > Unless that table's already in (mostly) index order, even cluster is > gonna be pretty painful. > I'd suggest a dump and reload myself. The run-time of CLUSTER doesn't vary very much based on whether the data is already in index order or not. The number of passes only grows like log(n) of the size of your data and if you set maintenance_work_mem large enough (somewhere around 100MB-1GB) the constants are small enough that you're unlikely to even outgrow a single pass (plus a final merge though) That said one sort is still more than zero. So a dump/reload is always going to be competitive depending on how slow your data is to compare versus how slow it is to convert to text and back (and how much larger the text is than the native format) -- greg
В списке pgsql-admin по дате отправления