From: | "Sebastian Ritter" <ritter(dot)sebastian(at)gmail(dot)com> |
---|---|
To: | "Richard Huxton" <dev(at)archonet(dot)com> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Query optimizing |
Date: | 2008-11-10 13:39:50 |
Message-ID: | 99b656cb0811100539q2128b39ch544ee8e2aa4ab1ea@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Cheers for you help guys. Having filtered and then joined has substantially
reduced the run time.
Much obliged,
Sebastian
On Mon, Nov 10, 2008 at 12:32 PM, Richard Huxton <dev(at)archonet(dot)com> wrote:
> Sebastian Ritter wrote:
> > Could it have something
> > to do with the fact that it is a subquery and thus the planner can not
> > deduce filtering conditions from the outer query against it? My
> apologises
> > if that made no sense.
>
> Could make a difference.
>
> > In summary, what im trying to understand is the following: Will there be
> a
> > performance difference between filtering query sets first and then
> joining
> > them together as opposed to joining first and then filtering? Does the
> > opitmiser not choose the best course of action either way yielding the
> same
> > result?
>
> There obviously is a performance difference between joining all of the
> issues table versus joining 1% of it to followups.
>
> In most cases the planner can push the condition into the subquery, but
> not in all cases because:
> 1. It's not provably correct to do so
> 2. The planner isn't smart enough to figure out that it can
>
> It's impossible to say which applies to you without knowing the full query.
>
> --
> Richard Huxton
> Archonet Ltd
>
From | Date | Subject | |
---|---|---|---|
Next Message | Mario Splivalo | 2008-11-10 14:01:33 | Using UTF strings in pg8.3 - storing hexadecimal values in bytea columns |
Previous Message | Richard Huxton | 2008-11-10 12:32:42 | Re: Query optimizing |