| From: | Ian Westmacott <ianw(at)intellivid(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: cost-based vacuum |
| Date: | 2005-07-13 18:40:36 |
| Message-ID: | 1121280036.13208.8.camel@spectre.intellivid.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, 2005-07-13 at 11:55, Simon Riggs wrote:
> On Tue, 2005-07-12 at 13:50 -0400, Ian Westmacott wrote:
> > It appears not to matter whether it is one of the tables
> > being written to that is ANALYZEd. I can ANALYZE an old,
> > quiescent table, or a system table and see this effect.
>
> Can you confirm that this effect is still seen even when the ANALYZE
> doesn't touch *any* of the tables being accessed?
Yes.
> > - this is a dual Xeon.
>
> Is that Xeon MP then?
Yes.
> > - Looking at oprofile reports for 10-minute runs of a
> > database-wide VACUUM with vacuum_cost_delay=0 and 1000,
> > shows the latter spending a lot of time in LWLockAcquire
> > and LWLockRelease (20% each vs. 2%).
>
> Is this associated with high context switching also?
Yes, it appears that context switches increase up to 4-5x
during cost-based ANALYZE.
--Ian
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dan Harris | 2005-07-13 18:54:35 | Quad Opteron stuck in the mud |
| Previous Message | Simon Riggs | 2005-07-13 16:10:06 | Re: General DB Tuning |