To: Mario Splivalo <mario.splivalo@megafon.hr>
cc: pgsql-performance@postgresql.org
Subject: Re: Planner choosing NestedLoop, although it is slower... 
In-reply-to: <4E1C8E62.2090800@megafon.hr> 
References: <4E1C8E62.2090800@megafon.hr>
Comments: In-reply-to Mario Splivalo <mario.splivalo@megafon.hr>
	message dated "Tue, 12 Jul 2011 20:11:46 +0200"
Date: Tue, 12 Jul 2011 16:04:12 -0400
Message-ID: <4626.1310501052@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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?

			regards, tom lane