Re: bad performances using hashjoin

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

In response to

Responses

Browse pgsql-performance by date

  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