Re: Removing INNER JOINs - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Removing INNER JOINs
Date
Msg-id CA+TgmoaxF2AFELa5imYR7H++3jPfi3kR=kRA0fQ0pgxYKRRr5Q@mail.gmail.com
Whole thread Raw
In response to Re: Removing INNER JOINs  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Removing INNER JOINs  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Removing INNER JOINs
Next
From: Tom Lane
Date:
Subject: Re: Removing INNER JOINs