Re: vacuum output question
От
Dan Armbrust
Тема
Re: vacuum output question
Дата
Msg-id
82f04dc40811140700n22437885q8b9b882a4d5130f2@mail.gmail.com
Ответ на
Re: vacuum output question (Simon Riggs)
Список
Дерево обсуждения
vacuum output question "Dan Armbrust" <daniel.armbrust.list@gmail.com>
Re: vacuum output question Tom Lane <tgl@sss.pgh.pa.us>
Re: vacuum output question "Scott Marlowe" <scott.marlowe@gmail.com>
Re: vacuum output question Simon Riggs <simon@2ndQuadrant.com>
Re: vacuum output question "Dan Armbrust" <daniel.armbrust.list@gmail.com>
Re: vacuum output question Simon Riggs <simon@2ndQuadrant.com>
Re: vacuum output question Craig Ringer <craig@postnewspapers.com.au>
Re: vacuum output question "Dan Armbrust" <daniel.armbrust.list@gmail.com>
> > There was concurrent access to the table during VACUUMing, so the long > delay is explainable as long waits for cleanup lock, plus probably > thrashing the cache with bloated indexes. The CPU overhead per row seems > OK. We should instrument the wait time during a VACUUM and report that > also. > > -- > Simon Riggs www.2ndQuadrant.com > PostgreSQL Training, Services and Support Is that a guess? Or something you can tell from the log above? Because there shouldn't have been any concurrent access while the VACUUM was run - the customers had failed over to a different system, so while I can't be sure, I expect that there was no other database activity at the time the command was run. Thanks, Dan
В списке pgsql-general по дате отправления
От: Willy-Bas Loos
Дата: