Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 7B3422E2D56 for ; Tue, 4 Mar 2008 13:19:24 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 17290-02-4 for ; Tue, 4 Mar 2008 13:19:18 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id B27222E2D3F for ; Tue, 4 Mar 2008 13:19:18 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m24HJHcV016226; Tue, 4 Mar 2008 12:19:17 -0500 (EST) To: "Kevin Grittner" cc: pgsql-performance@postgresql.org, "Chris Kratz" Subject: Re: Ramifications of turning off Nested Loops for slow queries In-reply-to: <47CD2203.EE98.0025.0@wicourts.gov> References: <483ACAF5-A485-40D9-9D7E-7008EF12F909@vistashare.com> <47CD2203.EE98.0025.0@wicourts.gov> Comments: In-reply-to "Kevin Grittner" message dated "Tue, 04 Mar 2008 10:18:43 -0600" Date: Tue, 04 Mar 2008 12:19:17 -0500 Message-ID: <16225.1204651157@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/55 X-Sequence-Number: 29009 "Kevin Grittner" writes: > On Tue, Mar 4, 2008 at 8:42 AM, in message > <483ACAF5-A485-40D9-9D7E-7008EF12F909@vistashare.com>, Chris Kratz > wrote: >> So, I've now been asked to ping the list as to whether turning off >> nested loops system wide is a bad idea, and why or why not. > In our environment, the fastest plan for a lot of queries involve > nested loops. Of course, it's possible that these never provide the > fasted plan in your environment, but it seems very unlikely -- > you're just not noticing the queries where it's doing fine. Yeah, I seem to recall similar queries from other people who were considering the opposite, ie disabling the other join types :-( The rule of thumb is that nestloop with an inner indexscan will beat anything else for pulling a few rows out of a large table. But on the other hand it loses big for selecting lots of rows. I don't think that a global disable in either direction would be a smart move, unless you run only a very small number of query types and have checked them all. regards, tom lane