Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 1D45B9FB289 for ; Wed, 27 Sep 2006 13:15:09 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 15847-06 for ; Wed, 27 Sep 2006 13:14:57 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by postgresql.org (Postfix) with ESMTP id A6A729FB32E for ; Wed, 27 Sep 2006 13:14:56 -0300 (ADT) Received: from collaborativefusion.com (mx01.pub.collaborativefusion.com [206.210.89.201]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Wed, 27 Sep 2006 12:14:55 -0400 id 00056437.451AA37F.00014368 Received: from Internal Mail-Server (206.210.89.202) by mx01 (envelope-from wmoran@collaborativefusion.com) with AES256-SHA encrypted SMTP; 27 Sep 2006 12:12:54 -0400 Date: Wed, 27 Sep 2006 12:14:54 -0400 From: Bill Moran To: Edoardo Ceccarelli Cc: pgsql-performance@postgresql.org, pgsql-admin@postgresql.org Subject: Re: [PERFORM] autovacuum on a -mostly- r/o table Message-Id: <20060927121454.36b9fc6c.wmoran@collaborativefusion.com> In-Reply-To: <451AA1FE.9050704@axa.it> References: <451AA1FE.9050704@axa.it> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.077 tagged_above=0 required=5 tests=AWL, UNPARSEABLE_RELAY X-Spam-Level: X-Archive-Number: 200609/328 X-Sequence-Number: 23242 In response to Edoardo Ceccarelli : > Hello, > > we are running a 7.3 postgres db with only a big table (avg > 500.000records) and 7 indexes for a search engine. > we have 2 of this databases and we can switch from one to another. > Last week we decided to give a try to 8.1 on one of them and everything > went fine, db is faster (about 2 or 3 times in our case) and the server > load is higher - which should mean that faster response time is achieved > by taking a better use of the server. > > We also activated the autovacuum feature to give it a try and that's > were our problems started. > I left the standard autovacuum configuration just to wait and see, pg > decided to start a vacuum on the table just midday when users were > launching search queries on the table and server load reached a very > high value so that in a couple of minutes the db was unusable > > With pg7.3 we use to vacuum the db night time, mostly because the insert > and updates in this table is made in a batch way: a single task that > puts 100.000 records in the db in 10/20minutes, so the best time to > actually vacuum the db would be after this batch. > > I have read that autovacuum cannot check to see pg load before launching > vacuum but is there any patch about it? that would sort out the problem > in a good and simple way. > Otherwise, which kind of set of parameters I should put in autovacuum > configuration? I am stuck because in our case the table gets mostly read > and if I set up things as to vacuum the table after a specific amount of > insert/updates, I cannot foresee whether this could happen during > daytime when server is under high load. > How can I configure the vacuum to run after the daily batch insert/update? It doesn't sound as if your setup is a good match for autovacuum. You might be better off going back to the cron vacuums. That's the beauty of Postgres -- it gives you the choice. If you want to continue with autovac, you may want to experiment with vacuum_cost_delay and associated parameters, which can lessen the impact of vacuuming. -- Bill Moran Collaborative Fusion Inc.