Cc: pgsql-admin@postgresql.org,"Sylvain CAILLET" <scaillet@alaloop.com>
Content-Type: text/plain; charset="utf-8"
Date: Mon, 31 Dec 2012 11:41:07 -0500
From: "Kevin Grittner" <kgrittn@mail.com>
Message-ID: <20121231164107.223680@gmx.com>
MIME-Version: 1.0
Subject: Re: Autovacuum issues with truncate and create index ...
To: "Baptiste LHOSTE" <blhoste@alaloop.com>
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

Baptiste LHOSTE wrote:

> These queries are very simple : delete from table where
> start_date < availableTimestamp. We performed an EXPLAIN to try
> to understand what could be the problem. The query planner said
> that the index on start_date could not be used because it was not
> up-to-date.

Could you show that output you base that on?

> How a server (8 CPUs) which has a 0.56 load over the last 15
> minutes could not handle 3 autovacuum processes, for me it is
> very confusing.

When the bottleneck is disk I/O the CPUs count is not going to
help. Threads which have not been context-switched out, but are
sitting waiting for the electric motors to drag the disk arm to the
right cylinder probably don't count against the load average.

Note that while three autovacuum processes normally don't cause any
grief, you seem to be near the tipping point anyway, so it may be a
case of "the straw that broke the camel's back". Especially since
you made autovacuum many times more resource-hungry than it is by
default.

-Kevin


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin