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 1A9DF9F931D for ; Mon, 8 May 2006 14:46:17 -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 66692-05 for ; Mon, 8 May 2006 14:46:06 -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 91DF49F931E for ; Mon, 8 May 2006 14:46:06 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 7E7AE56437; Mon, 8 May 2006 12:46:05 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Mon, 8 May 2006 12:46:04 -0500 Date: Mon, 8 May 2006 12:46:04 -0500 From: "Jim C. Nasby" To: Andrus Cc: pgsql-performance@postgresql.org Subject: Re: Query runs 38 seconds for small database! Message-ID: <20060508174604.GX99570@pervasive.com> References: <26838.1147099614@sss.pgh.pa.us> <27599.1147105626@sss.pgh.pa.us> <20060508172816.GU99570@pervasive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:060508:eetasoft@online.ee::zM5lNGoW9tThgISr:0000000000000000000 0000000000000000000000002sMM X-Hashcash: 1:20:060508:pgsql-performance@postgresql.org::8B6fZEmJNQaof59K:00000 0000000000000000000000004Q5x X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/144 X-Sequence-Number: 18931 On Mon, May 08, 2006 at 08:36:42PM +0300, Andrus wrote: > > BTW, you might want to cut all the autovac thresholds in half; that's > > what I typically do. > > I added ANALYZE command to my procedure which creates and loads data to > postgres database > from other DBMS. This runs only onvce after installing my application. I > hope this is sufficient. > If default threshold is so conservative values I expect there is some reason > for it. The only reason for being so conservative that I'm aware of was that it was a best guess. Everyone I've talked to cuts the defaults down by at least a factor of 2, sometimes even more. BTW, these parameters are already tweaked from what we started with in contrib/pg_autovacuum. It would allow a table to grow to 2x larger than it should be before vacuuming, as opposed to the 40% that the current settings allow. But even there, is there any real reason you want to have 40% bloat? To make matters worse, those settings ensure that all but the smallest databases will suffer runaway bloat unless you bump up the FSM settings. -- 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