X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 810A19FA1E2 for ; Wed, 13 Sep 2006 17:09:21 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 90430-05 for ; Wed, 13 Sep 2006 20:09:13 +0000 (UTC) X-Greylist: delayed 00:26:08.658698 by SQLgrey- Received: from smtp.elde.net (us.elde.net [66.246.223.215]) by postgresql.org (Postfix) with ESMTP id 86E5A9FA089 for ; Wed, 13 Sep 2006 17:09:13 -0300 (ADT) Received: from smtp.elde.net (343006.ds.nac.net [127.0.0.1]) by smtp.elde.net (Postfix) with ESMTP id 42A3B65036; Wed, 13 Sep 2006 21:43:03 +0200 (CEST) Received: from [10.137.1.101] (115.80-203-96.nextgentel.com [80.203.96.115]) (Authenticated sender: terje@elde.net) by smtp.elde.net (Postfix) with ESMTP id 42B7A65007; Wed, 13 Sep 2006 21:43:02 +0200 (CEST) Message-ID: <45085F3A.1040108@elde.net> Date: Wed, 13 Sep 2006 21:42:50 +0200 From: Terje Elde User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Jeff Davis CC: Joshua Marsh , pgsql-performance@postgresql.org, jim@nasby.net Subject: Re: Performance With Joins on Large Tables References: <38242de90609121517y62517040v8622b9ae93cba23d@mail.gmail.com> <20060913064152.GC23173@nasby.net> <38242de90609130749u976295fwb10904ff4797b920@mail.gmail.com> <1158163655.29889.57.camel@dogma.v10.wvs> <38242de90609130919k33208204ka1006ff0ca25f75b@mail.gmail.com> <1158167054.29889.72.camel@dogma.v10.wvs> In-Reply-To: <1158167054.29889.72.camel@dogma.v10.wvs> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.134 tagged_above=0 required=5 tests=FORGED_RCVD_HELO, SPF_PASS X-Spam-Level: X-Archive-Number: 200609/130 X-Sequence-Number: 20816 Jeff Davis wrote: > Is it overestimating the cost of using indexes or underestimating the > cost of a seq scan, or both? Maybe explain with the 0.1 setting will > help? > If enable_seqscan is off, and cost is still set to 100000000, it could be that it's quite simply forcibly underestimating the cost of a seqscan in this case. If enable_secscan was off for the mentioned plan, it'd be interesting to see if things would be saner with seqscans enabled, and a more reasonable random page cost. If more 'sane' values still produce the desired plan, it might be better for other plans etc. Terje