| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Dan Armbrust <daniel(dot)armbrust(dot)list(at)gmail(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:10:54 |
| Message-ID: | 1226675454.27904.599.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, 2008-11-14 at 09:00 -0600, Dan Armbrust wrote:
> > 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.
> Is that a guess? Or something you can tell from the log above?
The number of row versions in each index was different after vacuuming.
That tells me some writes occurred and I inferred from that that other
read-only activity occurred as well. Reads or writes will slow down a
VACUUM.
Perhaps you have vacuum_cost_delay set also?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | tv | 2008-11-14 15:14:03 | Re: Tweaking PG (again) |
| Previous Message | Dan Armbrust | 2008-11-14 15:00:14 | Re: vacuum output question |