Re: order of nested loop

Joseph Shraibman  writes:
> Well there is no reason for it to look at all the rows in d, since it
> has a filter on u that should produce much less rows than there on in
> d.

What filter?  The scan is producing 250 thousand rows, man!  You expect
it to join 250k rows in no time flat?

You can try forcing merge or nestloop joins with the enable_foo
switches, but I suspect you'll find that for the problem as posed,
this is the best plan available.  To make it go faster you will need a
way to eliminate a large percentage of one or both tables before the
join happens.

			regards, tom lane