From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tobias Brox <tobias@nordicbet.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Merge Join vs Nested Loop
Date: Tue, 26 Sep 2006 18:09:56 -0400
Message-ID: <719.1159308596@sss.pgh.pa.us> (raw)
In-Reply-To: <20060926193553.GA27268@oppetid.no>
References: <20060926193553.GA27268@oppetid.no>
Tobias Brox <tobias@nordicbet.com> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, tobias@nordicbet.com
Subject: Re: Merge Join vs Nested Loop
In-Reply-To: <719.1159308596@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox