Re: left join + case - how is it processed?

From: Chris <dmagick(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Evan Carroll <lists(at)evancarroll(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: left join + case - how is it processed?
Date: 2009-01-19 22:12:04
Message-ID: 4974FAB4.9020803@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Tom Lane wrote:
> Chris <dmagick(at)gmail(dot)com> writes:
>> I can see it's doing the extra filter step at the start (4th line) which
>> is not present without the coalesce/case statement. I just don't
>> understand why it's being done at that stage.
>
> It's not that hard to understand. With the original view formulation
> (or the COALESCE version), the fully expanded form of the query looks
> like
>
> select ... from p left join r ...
> where expression_involving_both_p_and_r = constant
>
> If you make the view output be just p.assetid then you have
>
> select ... from p left join r ...
> where p.assetid = constant
>
> In the first case the planner cannot apply the WHERE restriction until
> it's formed the p+r join; so you see the condition applied as a filter
> on the join node's output. In the second case, the planner can push the
> WHERE restriction down into the scan of p, since the left join doesn't
> affect it. (If a p row doesn't pass the restriction, then no join row
> formed from it can either; ergo there is no need to form those join rows
> at all.)

So because the CASE is on (some of) the fields I'm joining on, in effect
it's made part of the join condition. If the fields are outside that
(r.userid/p.userid), then it's evaluated after.

Thanks!

--
Postgresql & php tutorials
http://www.designmagick.com/

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Yannick Le Guédart 2009-01-20 15:45:45 Interesting query plan change linked to the LIMIT parameter
Previous Message Akos Gabriel 2009-01-19 18:07:10 Query running long - cost estimation question...