From: Mario Splivalo <mario.splivalo@megafon.hr>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: Planner choosing NestedLoop, although it is slower...
Date: Wed, 13 Jul 2011 00:06:46 +0200
Message-ID: <4E1CC576.2080200@megafon.hr> (raw)
In-Reply-To: <4626.1310501052@sss.pgh.pa.us>
References: <4E1C8E62.2090800@megafon.hr>
<4626.1310501052@sss.pgh.pa.us>
On 07/12/2011 10:04 PM, Tom Lane wrote:
> Mario Splivalo<mario.splivalo@megafon.hr> writes:
>> Limit (cost=0.00..415.91 rows=21 width=8) (actual
>> time=11263.089..11263.089 rows=0 loops=1)
>> -> Nested Loop (cost=0.00..186249.55 rows=9404 width=8) (actual
>> time=11263.087..11263.087 rows=0 loops=1)
>
>> Why is planner using NestedLoops,
>
> Because it thinks the LIMIT will kick in and end the query when the join
> is only 21/9404ths (ie, a fraction of a percent) complete. A NestLoop
> results in saving a lot of work in that situation, whereas hash-and-sort
> has to do the whole join despite the LIMIT.
>
> What you need to look into is why the estimated join size is 9400 rows
> when the actual join size is zero. Are both tables ANALYZEd? Are you
> intentionally selecting rows that have no join partners?
Hi, Tom.
Yes, both tables have been ANALYZEd. What do you mean, intentilnaly
selecting rows taht have no join partners?
Mario
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: mario.splivalo@megafon.hr, tgl@sss.pgh.pa.us
Subject: Re: Planner choosing NestedLoop, although it is slower...
In-Reply-To: <4E1CC576.2080200@megafon.hr>
* 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