X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id C47259FA278 for ; Fri, 19 May 2006 17:21:52 -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 82473-05 for ; Fri, 19 May 2006 17:21:42 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 69A9C9FA22C for ; Fri, 19 May 2006 17:21:40 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 4FC9756435; Fri, 19 May 2006 15:21:38 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Fri, 19 May 2006 15:21:36 -0500 Date: Fri, 19 May 2006 15:21:35 -0500 From: "Jim C. Nasby" To: Jean-Paul Argudo Cc: Olivier Andreotti , pgsql-performance@postgresql.org Subject: Re: Benchmarck PostgreSQL 8.1.4 MySQL 5.0.20 and Oracle Message-ID: <20060519202134.GM64371@pervasive.com> References: <446C510A.9040609@argudo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <446C510A.9040609@argudo.org> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060519:jean-paul@argudo.org::pwRZ+6CyFYDnuef9:00000000000000000 0000000000000000000000003nGp X-Hashcash: 1:20:060519:olivier.andreotti@gmail.com::TcXgzyq6BaFQjaIT:0000000000 0000000000000000000000008C4A X-Hashcash: 1:20:060519:pgsql-performance@postgresql.org::ltFBlKn+jtp6zcG3:00000 0000000000000000000000004va6 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/404 X-Sequence-Number: 19191 On Thu, May 18, 2006 at 12:48:42PM +0200, Jean-Paul Argudo wrote: > > autovaccuum = on > > Thats a critic point. Personaly I dont use autovacuum. Because I just > don't want a vacuum to be started ... when the server is loaded :) > > I prefer control vacuum process, when its possible (if its not, > autovacuum is the best choice!), for example, a nighlty vacuum... This can be problematic for a benchmark, which often will create dead tuples at a pretty good clip. In any case, if you are going to use autovacuum, you should cut all the thresholds and scale factors in half, and set cost_delay to something (I find 5-10 is usually good). Depending on your write load, you might need to make the bgwriter more aggressive, too. If you can graph some metric from your benchmark over time it should be pretty easy to spot if the bgwriter is keeping up with things or not; if it's not, you'll see big spikes every time there's a checkpoint. > A question for you: after setting up your test database, did you launch > a vacuum full analyze of it ? Why would you vacuum a newly loaded database that has no dead tuples? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461