Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 630A29FB32C; Wed, 27 Sep 2006 13:08:18 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 23330-06; Wed, 27 Sep 2006 16:08:14 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 0F4AE9FB32E; Wed, 27 Sep 2006 13:08:14 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from www.axa.it (www.axa.it [194.242.232.5]) by svr4.postgresql.org (Postfix) with ESMTP id 5C05C5AF880; Wed, 27 Sep 2006 16:08:13 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.axa.it (Postfix) with ESMTP id 159F6A5044B; Wed, 27 Sep 2006 18:08:11 +0200 (CEST) Received: from www.axa.it ([127.0.0.1]) by localhost (www.axa.it [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10957-02-13; Wed, 27 Sep 2006 18:08:08 +0200 (CEST) Received: from [192.168.0.71] (adsl-ull-84-199.48-151.net24.it [151.48.199.84]) by www.axa.it (Postfix) with ESMTP id EFA49A50442; Wed, 27 Sep 2006 18:08:07 +0200 (CEST) Message-ID: <451AA1FE.9050704@axa.it> Date: Wed, 27 Sep 2006 18:08:30 +0200 From: Edoardo Ceccarelli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Cc: pgsql-admin@postgresql.org Subject: autovacuum on a -mostly- r/o table Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at axa.it X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200609/325 X-Sequence-Number: 23239 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? Any help appreciated Thank you very much Edoardo