Re: bad performances using hashjoin - Mailing list pgsql-performance

From Tom Lane
Subject Re: bad performances using hashjoin
Date
Msg-id 15413.1108925170@sss.pgh.pa.us
Whole thread Raw
In response to bad performances using hashjoin  (Gaetano Mendola <mendola@bigfoot.com>)
Responses Re: bad performances using hashjoin  (Gaetano Mendola <mendola@bigfoot.com>)
Re: bad performances using hashjoin  (Klint Gore <kg@kgb.une.edu.au>)
Re: bad performances using hashjoin  (David Brown <time@bigpond.net.au>)
List pgsql-performance
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

pgsql-performance by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: seq scan cache vs. index cache smackdown
Next
From: Mark Kirkwood
Date:
Subject: Re: Problem with 7.4.5 and webmin 1.8 in grant function