Skip site navigation (1) Skip section navigation (2)

Re: updated join removal patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: updated join removal patch
Date: 2009-09-18 19:46:06
Message-ID: 603c8f070909181246i235f9a46s361c06fa13f85d51@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Sep 18, 2009 at 3:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Sep 18, 2009 at 1:58 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>> Mmm, I like that.  Putting that bunch of hairy logic in a subroutine
>>>> instead of repeating it in several places definitely seems better.  I
>>>> don't really like the name "clause_matches_join", though.
>
>>> It was the first thing that came to mind ... got a better idea?
>
>> clause_has_well_defined_sides()?
>
> Nah ... they're "well defined" in any case, they might just not be what
> we need for the current join.  As an example,
>
>        (a.f1 + b.f2) = c.f3
>
> would be usable if joining {A B} to {C}, but not when joining
> {A} to {B C}.

The clauses are well-defined, but they don't have well-defined sides.
I see now what you're going for with clause_matches_join, but
"matches" is a pretty broad term, IMO.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-09-18 19:52:15
Subject: Re: updated join removal patch
Previous:From: Simon RiggsDate: 2009-09-18 19:44:34
Subject: Re: FSM search modes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group