Re: WIP Join Removal

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: List pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: WIP Join Removal
Date: 2008-09-02 11:20:13
Message-ID: 1220354413.4371.365.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


On Tue, 2008-09-02 at 14:03 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Tue, 2008-09-02 at 13:41 +0300, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> On Tue, 2008-09-02 at 13:20 +0300, Heikki Linnakangas wrote:
> >>>> Simon Riggs wrote:
> >>>>> It turns out that a join like this
> >>>>>
> >>>>> select a.col2
> >>>>> from a left outer join b on a.col1 = b.col1
> >>>>> where b.col2 = 1;
> >>>>>
> >>>>> can be cheaper if we don't remove the join, when there is an index on
> >>>>> a.col1 and b.col2, because the presence of b allows the values returned
> >>>>> from b to be used for an index scan on a.
> >>>> Umm, you *can't* remove that join.
> >>> Yes, you can. The presence or absence of rows in b is not important to
> >>> the result of the query because of the "left outer join".
> >>>
> >>> I spent nearly a whole day going down that deadend also.
> >> Oh. How does the query look like after removing the join, then?
> >
> > Same answer, just slower. Removing the join makes the access to a into a
> > SeqScan, whereas it was a two-table index plan when both tables present.
> > The two table plan is added by the immediately preceding call add_... -
> > i.e. that plan is only added during join time not during planning of
> > base relations.
>
> I mean, can you how me an SQL query of what's left after removing the
> join? Certainly just removing the join and the WHERE clause doesn't give
> the same answer.

Yes, it does

select a.col2
from a left outer join b on a.col1 = b.col1
where b.col2 = 1;

is logically equivalent to

select a.col2
from a;

and hence removing the join produces a SeqScan plan, whereas the
equivalent join can in some circumstances be faster.

I discovered this, I didn't think of it in advance.

> Or is it something that can't be expressed with SQL?
> What's the filter in the SeqScan?

There is no filter in the SeqScan. Try some queries and you'll see what
I mean.

I've said its a dead end and that I spent hours thinking that, so please
think about this...

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Heikki Linnakangas 2008-09-02 11:20:41 Re: WIP Join Removal
Previous Message Gregory Stark 2008-09-02 11:05:38 Re: WIP Join Removal