Date: Wed, 27 Sep 2006 17:26:55 +0200
From: Tobias Brox <tobias@nordicbet.com>
To: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: Tobias Brox <tobias@nordicbet.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-performance@postgresql.org
Subject: Re: Merge Join vs Nested Loop
Message-ID: <20060927152655.GF17834@oppetid.no>
References: <20060926193553.GA27268@oppetid.no> <719.1159308596@sss.pgh.pa.us>
	<20060927094803.GA11245@oppetid.no>
	<1159369111.4643.0.camel@localhost.localdomain>
	<20060927150512.GE17834@oppetid.no>
	<1159370365.4643.7.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1159370365.4643.7.camel@localhost.localdomain>
Organization: Group Nordicbet
User-Agent: Mutt/1.5.9i

[Scott Marlowe - Wed at 10:19:24AM -0500]
> So, by decreasing them, you should move away from nested loops then,
> right?  Has that not worked for some reason?

I want to move to nested loops, they are empirically faster in many of
our queries, and that makes sense since we've got quite big tables and
most of the queries only touch a small partition of the data.

I've identified that moving any of the cost constants (including
random_page_cost) upwards gives me the right result, but I'm still wary
if this is the right thing to do.  Even if so, what constants should I
target first?  I could of course try to analyze a bit what constants
give the biggest impact.  Then again, we have many more queries hitting
the database than the few I'm doing research into (and those I'm doing
research into is even very simplified versions of the real queries).