Cheers for you help guys. Having filtered and then joined has substantially reduced the run time.<br /><br />Much
obliged,<br/>Sebastian<br /><br /><div class="gmail_quote">On Mon, Nov 10, 2008 at 12:32 PM, Richard Huxton <span
dir="ltr"><<ahref="mailto:dev@archonet.com">dev@archonet.com</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;"><divclass="Ih2E3d">Sebastian Ritter wrote:<br /> > Could it have something<br /> > to do with the fact that
itis a subquery and thus the planner can not<br /> > deduce filtering conditions from the outer query against it? My
apologises<br/> > if that made no sense.<br /><br /></div>Could make a difference.<br /><div class="Ih2E3d"><br />
>In summary, what im trying to understand is the following: Will there be a<br /> > performance difference
betweenfiltering query sets first and then joining<br /> > them together as opposed to joining first and then
filtering?Does the<br /> > opitmiser not choose the best course of action either way yielding the same<br /> >
result?<br/><br /></div>There obviously is a performance difference between joining all of the<br /> issues table
versusjoining 1% of it to followups.<br /><br /> In most cases the planner can push the condition into the subquery,
but<br/> not in all cases because:<br /> 1. It's not provably correct to do so<br /> 2. The planner isn't smart
enoughto figure out that it can<br /><br /> It's impossible to say which applies to you without knowing the full
query.<br/><font color="#888888"><br /> --<br /> Richard Huxton<br /> Archonet Ltd<br /></font></blockquote></div><br
/>
