From: Simon Riggs <simon@2ndquadrant.com>
To: Ian Westmacott <ianw@intellivid.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: cost-based vacuum
Date: Wed, 13 Jul 2005 16:55:50 +0100
Message-ID: <1121270150.3970.256.camel@localhost.localdomain> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: simon@2ndquadrant.com, ianw@intellivid.com, tgl@sss.pgh.pa.us
Subject: Re: cost-based vacuum
In-Reply-To: <1121270150.3970.256.camel@localhost.localdomain>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox