Re: updated join removal patch
От | Robert Haas |
---|---|
Тема | Re: updated join removal patch |
Дата | |
Msg-id | 603c8f070909181246i235f9a46s361c06fa13f85d51@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: updated join removal patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: updated join removal patch
|
Список | pgsql-hackers |
On Fri, Sep 18, 2009 at 3:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Sep 18, 2009 at 1:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: