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 7D8379F931D for ; Mon, 8 May 2006 15:10:40 -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 69721-06 for ; Mon, 8 May 2006 15:10:26 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id 8AEE59FA2DB for ; Mon, 8 May 2006 15:10:26 -0300 (ADT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 80E50314E2; Mon, 8 May 2006 20:10:25 +0200 (MET DST) From: "Andrus" X-Newsgroups: pgsql.performance Subject: Re: Query runs 38 seconds for small database! Date: Mon, 8 May 2006 21:10:07 +0300 Organization: Hub.Org Networking Services Lines: 22 Message-ID: References: <26838.1147099614@sss.pgh.pa.us> <27599.1147105626@sss.pgh.pa.us> <20060508172816.GU99570@pervasive.com> <20060508174604.GX99570@pervasive.com> X-Complaints-To: usenet@news.hub.org X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-RFC2646: Format=Flowed; Original To: pgsql-performance@postgresql.org X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/147 X-Sequence-Number: 18934 > 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. Can we ask that Tom will change default values to 2 times smaller in 8.1.4 ? > 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 recprd> the FSM settings. I created empty table konto and loaded more that 219 records to it during database creation. So it seems that if table grows from zero to more than 219 times larger then it was still not processed. Andrus.