Re: bad performances using hashjoin

Gaetano Mendola <mendola@bigfoot.com> writes:
> If you need other info in order to improve the planner,

... like, say, the PG version you are using, or the definitions of the
views involved?  It's difficult to say much of anything about this.

However: the reason the second plan wins is because there are zero rows
fetched from sat_request, and so the bulk of the plan is never executed
at all.  I doubt the second plan would win if there were any matching
sat_request rows.  If this is the case you actually need to optimize,
probably the thing to do is to get rid of the ORDER BY clauses you
evidently have in your views, so that there's some chance of building
a fast-start plan.

BTW, I believe in 8.0 the first plan would be about as fast as the
second, because we added some code to hash join to fall out without
scanning the left input if the right input is empty.

            regards, tom lane