From: | "Dan Armbrust" <daniel(dot)armbrust(dot)list(at)gmail(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "pgsql general" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: vacuum output question |
Date: | 2008-11-14 15:00:14 |
Message-ID: | 82f04dc40811140700n22437885q8b9b882a4d5130f2@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-11-14 15:10:54 | Re: vacuum output question |
Previous Message | Willy-Bas Loos | 2008-11-14 14:58:33 | Re: [pgsql-general] cant find postgres executable after initdb |