Date: Tue, 23 Oct 2007 13:12:04 -0300
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Ron St-Pierre <ron.pgsql@shaw.ca>
Cc: pgsql-performance@postgresql.org
Subject: Re: 12 hour table vacuums
Message-ID: <20071023161204.GK18013@alvh.no-ip.org>
References: <471E18ED.3090704@shaw.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <471E18ED.3090704@shaw.ca>
User-Agent: Mutt/1.5.16 (2007-06-11)

Ron St-Pierre wrote:

> Okay, here's our system:
>   postgres 8.1.4

Upgrade to 8.1.10

> Here's the table information:
> The table has 140,000 rows, 130 columns (mostly NUMERIC), 60 indexes.

60 indexes?  You gotta be kidding.  You really have 60 columns on which
to scan?

> vacuum_cost_delay = 200
> vacuum_cost_limit = 100

Isn't this a bit high?  What happens if you cut the delay to, say, 10?
(considering you've lowered the limit to half the default)

-- 
Alvaro Herrera                          Developer, http://www.PostgreSQL.org/
"Someone said that it is at least an order of magnitude more work to do
production software than a prototype. I think he is wrong by at least
an order of magnitude."                              (Brian Kernighan)