Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id EABFB2E00D8
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Tue,  4 Mar 2008 12:19:02 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 99596-04 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Tue,  4 Mar 2008 12:18:56 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from gwmta.wicourts.gov (gwmta.wicourts.gov [165.219.244.99])
	by postgresql.org (Postfix) with ESMTP id E642E2E00DD
	for <pgsql-performance@postgresql.org>;
	Tue,  4 Mar 2008 12:18:55 -0400 (AST)
Received: from Courts-MTA by gwmta.wicourts.gov
	with Novell_GroupWise; Tue, 04 Mar 2008 10:18:53 -0600
Message-Id: <47CD2203.EE98.0025.0@wicourts.gov>
X-Mailer: Novell GroupWise Internet Agent 7.0.2 
Date: Tue, 04 Mar 2008 10:18:43 -0600
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: <pgsql-performance@postgresql.org>,
	"Chris Kratz" <chris.kratz@vistashare.com>
Subject: Re: Ramifications of turning off Nested Loops for
	slow queries
References: <483ACAF5-A485-40D9-9D7E-7008EF12F909@vistashare.com>
In-Reply-To: <483ACAF5-A485-40D9-9D7E-7008EF12F909@vistashare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200803/53
X-Sequence-Number: 29007

>>> On Tue, Mar 4, 2008 at  8:42 AM, in message
<483ACAF5-A485-40D9-9D7E-7008EF12F909@vistashare.com>, Chris Kratz
<chris.kratz@vistashare.com> wrote:=20
=20
> So, I've now been asked to ping the list as to whether turning off =20
> nested loops system wide is a bad idea, and why or why not.
=20
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.
=20
> Any other thoughts or suggestions?
=20
Make sure your effective_cache_size is properly configured.
=20
Increase random_page_cost and/or decrease seq_page_cost.
You can play with the cost settings on a connection, using EXPLAIN
on the query, to see what plan you get with each configuration
before putting it into the postgresql.conf file.
=20
-Kevin
=20