Re: Removing INNER JOINs

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Removing INNER JOINs
Дата
Msg-id CA+TgmoaxF2AFELa5imYR7H++3jPfi3kR=kRA0fQ0pgxYKRRr5Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Removing INNER JOINs  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Removing INNER JOINs  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Dec 3, 2014 at 11:23 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> Well, the planstate tree is what determines the execution, right? I
> don't see what would stop us from doing something like replacing:
> PlanState *
> ExecInitNode(Plan *node, EState *estate, int eflags)
> {
> ...
>         case T_NestLoop:
>             result = (PlanState *) ExecInitNestLoop((NestLoop *) node,
>                                                     estate, eflags);
> by
>         case T_NestLoop:
>                         if (JoinCanBeSkipped(node))
>                             result = NonSkippedJoinNode(node);
>                         else
>                             result = (PlanState *) ExecInitNestLoop((NestLoop *) node,
>                                                     estate, eflags);
>
> Where JoinCanBeSkipped() and NonSkippedJoinNode() contain the logic
> from David's early patch where he put the logic entirely into the actual
> execution phase.

Yeah, maybe.  I think there's sort of a coding principle that the plan
and planstate trees should match up one-to-one, but it's possible that
nothing breaks if they don't, or that I've misunderstood the coding
rule in the first instance.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Removing INNER JOINs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Removing INNER JOINs