> > 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
