<[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