From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gaetano Mendola <mendola(at)bigfoot(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: bad performances using hashjoin |
Date: | 2005-02-20 18:46:10 |
Message-ID: | 15413.1108925170@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Gaetano Mendola <mendola(at)bigfoot(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2005-02-20 22:58:43 | Re: Problem with 7.4.5 and webmin 1.8 in grant function |
Previous Message | Magnus Hagander | 2005-02-20 18:25:33 | Re: seq scan cache vs. index cache smackdown |