<[EMAIL PROTECTED]> writes:
> Aha!  set hashjoin=off did the trick.

>                ->  Index Scan using ix_user_url_tag_user_url_id on 
> user_url_tag userurltag0_  (cost=0.00..157.34 rows=103 width=14) (actual 
> time=1.223..1.281 rows=5 loops=1666)
>                      Index Cond: (userurltag0_.user_url_id = "outer".id)

This seems to be the problem right here: the estimate of matching rows
is off by a factor of 20, and that inflates the overall cost estimate
for this plan about the same, causing the planner to think the other way
is cheaper.

What does the pg_stats row for user_url_tag.user_url_id contain?
Have you analyzed that table recently?

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to