Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 65D349FB1E1 for ; Wed, 27 Sep 2006 17:28: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 85596-07 for ; Wed, 27 Sep 2006 17:27:59 -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 BE7609FB1E6 for ; Wed, 27 Sep 2006 17:27:58 -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 16:27:57 -0400 id 00056438.451ADECD.00016460 Received: from Internal Mail-Server (206.210.89.202) by mx01 (envelope-from wmoran@collaborativefusion.com) with AES256-SHA encrypted SMTP; 27 Sep 2006 16:25:54 -0400 Date: Wed, 27 Sep 2006 16:27:56 -0400 From: Bill Moran To: Edoardo Ceccarelli Cc: pgsql-performance@postgresql.org Subject: Re: autovacuum on a -mostly- r/o table Message-Id: <20060927162756.0a9df264.wmoran@collaborativefusion.com> References: <451AA1FE.9050704@axa.it> <1159374712.46586.47.camel@home> 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.075 tagged_above=0 required=5 tests=AWL, UNPARSEABLE_RELAY X-Spam-Level: X-Archive-Number: 200609/371 X-Sequence-Number: 21057 In response to Edoardo Ceccarelli : > Rod Taylor wrote: > > On Wed, 2006-09-27 at 18:08 +0200, Edoardo Ceccarelli wrote: > > > >> 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. > >> > > > > In some cases the solution to high load is to vacuum the tables being > > hit the heaviest -- meaning that simply checking machine load isn't > > enough to make that decision. > > > > In fact, that high load problem is exactly why autovacuum was created in > > the first place. > > > True, > but autovacuum could check load -before- and -during- it's execution and > it could adjust himself automatically to perform more or less > aggressively depending on the difference between those two values. > Maybe with a parameter like: maximum-autovacuum-load=0.2 > that would mean: "never load the machine more than 20% for the autovacuum" This is pretty non-trivial. How do you define 20% load? 20% of the CPU? Does that mean that it's OK for autovac to use 3% cpu and 100% of your IO? Ok, so we need to calculate an average of IO and CPU -- which disks? If your WAL logs are on one disk, and you've used tablespaces to spread the rest of your DB across different partitions, it can be pretty difficult to determine which IO parameters you want to take into consideration. -- Bill Moran Collaborative Fusion Inc. **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****************************************************************