Subject: Re: cost-based vacuum
From: Simon Riggs <simon@2ndquadrant.com>
To: Ian Westmacott <ianw@intellivid.com>,
	Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
In-Reply-To: <1121190651.10346.342.camel@spectre.intellivid.com>
References: <1120839902.20657.197.camel@spectre.intellivid.com>
	<1121081504.3970.53.camel@localhost.localdomain>
	<1121087266.27427.35.camel@spectre.intellivid.com>
	<1121093488.3970.70.camel@localhost.localdomain>
	<1121154338.3970.106.camel@localhost.localdomain>
	<1121190651.10346.342.camel@spectre.intellivid.com>
Content-Type: text/plain
Organization: 2nd Quadrant
Date: Wed, 13 Jul 2005 16:55:50 +0100
Message-Id: <1121270150.3970.256.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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?

> - this is a dual Xeon. 

Is that Xeon MP then?

> - 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?

Best Regards, Simon Riggs