Re: Removing INNER JOINs

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mart Kelder <mart(at)kelder31(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Removing INNER JOINs
Date: 2014-12-03 16:56:50
Message-ID: CA+TgmoaxF2AFELa5imYR7H++3jPfi3kR=kRA0fQ0pgxYKRRr5Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 3, 2014 at 11:23 AM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-12-03 17:08:01 Re: Removing INNER JOINs
Previous Message Stephen Frost 2014-12-03 16:45:28 Re: Removing INNER JOINs