Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 2BF0A9FA433 for ; Tue, 26 Sep 2006 19:10:10 -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 23632-09 for ; Tue, 26 Sep 2006 22:10:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 417929FA3AD for ; Tue, 26 Sep 2006 19:09:59 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k8QM9u41000720; Tue, 26 Sep 2006 18:09:57 -0400 (EDT) To: Tobias Brox cc: pgsql-performance@postgresql.org Subject: Re: Merge Join vs Nested Loop In-reply-to: <20060926193553.GA27268@oppetid.no> References: <20060926193553.GA27268@oppetid.no> Comments: In-reply-to Tobias Brox message dated "Tue, 26 Sep 2006 21:35:53 +0200" Date: Tue, 26 Sep 2006 18:09:56 -0400 Message-ID: <719.1159308596@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200609/339 X-Sequence-Number: 21025 Tobias Brox writes: > What causes the nested loops to be estimated so costly - or is it the > merge joins that are estimated too cheaply? Should I raise all the > planner cost constants, or only one of them? If your tables are small enough to fit (mostly) in memory, then the planner tends to overestimate the cost of a nestloop because it fails to account for cacheing effects across multiple scans of the inner table. This is addressed in 8.2, but in earlier versions about all you can do is reduce random_page_cost, and a sane setting of that (ie not less than 1.0) may not be enough to push the cost estimates where you want them. Still, reducing random_page_cost ought to be your first recourse. regards, tom lane