X-Original-To: pgsql-performance@postgresql.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 8A871476334; Wed, 7 May 2003 09:40:54 -0400 (EDT) Received: from fuji.krosing.net (sein.itera.ee [194.126.109.126]) by postgresql.org (Postfix) with ESMTP id 1DC32475EDF; Wed, 7 May 2003 09:40:26 -0400 (EDT) Received: from fuji.krosing.net (lo [127.0.0.1]) by fuji.krosing.net (8.12.8/8.12.8) with ESMTP id h47DeErK002547; Wed, 7 May 2003 16:40:14 +0300 Received: (from hannu@localhost) by fuji.krosing.net (8.12.8/8.12.8/Submit) id h47De6Qk002544; Wed, 7 May 2003 16:40:06 +0300 X-Authentication-Warning: fuji.krosing.net: hannu set sender to hannu@tm.ee using -f Subject: Re: An unresolved performance problem. From: Hannu Krosing To: Achilleus Mantzios Cc: pgsql-sql@postgresql.org, pgsql-performance@postgresql.org, pgsql-bugs@postgresql.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1052314806.2205.6.camel@fuji.krosing.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 07 May 2003 16:40:06 +0300 X-Spam-Status: No, hits=-33.7 required=5.0 tests=BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_XIMIAN,X_AUTH_WARNING autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200305/77 X-Sequence-Number: 1856 Achilleus Mantzios kirjutas K, 07.05.2003 kell 19:33: > Hi, few days ago, i posted some really wierd (at least to me) > situation (maybe a potentian bug) to the performance and bugs list > and to some core hacker(s) privately as well, > and i got no response. > Moreover i asked for some feedback > in order to understand/fix the problem myself, > and again received no response. > > What i asked was pretty simple: > "1. Is it possible that the absense of statistics make the planer produce > better plans than in the case of statistcs generated with vacuum > analyze/analyze? Yes, the planner is not perfect, the statistics are just statistics (based on a random sample), etc.. This question comes up at least once a month on either [PERFORM] or [HACKERS], search the mailing lists to get more thorough discussion/explanation. > 2. If No, i found a bug, Rather a feature ;-p > 3. If yes then under what conditions?? if 1) ANALYZE produced skewed data which was worse than default. or. 2) some costs are way off for your system (try changing them in postgresql.conf) > 4. If no person knows the answer or no hacker wants to dig into the > problem then is there a direction i must follow to understand/fix whats > going on myself??"" You can sturt by enabling/disabling various scan methods psqldb# set enable_seqscan to off; SET and see what happens, then adjust the weights in postgresql.conf or use some combination of SETs around critical queries to force the plan you like. ------------ Hannu