Re: Removing INNER JOINs

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(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:23:17
Message-ID: 20141203162317.GA27550@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-12-03 11:11:49 -0500, Robert Haas wrote:
> On Wed, Dec 3, 2014 at 10:56 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > On 2014-12-03 10:51:19 -0500, Robert Haas wrote:
> >> On Wed, Dec 3, 2014 at 4:29 AM, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> >> > *** Method 1: Removing Inner Joins at planning time:
> >> >
> >> > *** Method 2: Marking scans as possibly skippable during planning, and
> >> > skipping joins at execution (Andres' method)
> >> >
> >> > *** Method 3: Marking scans as possibly skippable during planning and
> >> > removing redundant join nodes at executor startup (Simon's method)
> >> [....]
> >> > a. can we invoke the planner during executor init?
> >>
> >> I'm pretty sure that we can't safely invoke the planner during
> >> executor startup, and that doing surgery on the plan tree (option #3)
> >> is unsafe also. I'm pretty clear why the latter is unsafe: it might
> >> be a copy of a data structure that's going to be reused.
> >
> > We already have a transformation between the plan and execution
> > tree.
>
> We do?
>
> I think what we have is a plan tree, which is potentially stored in a
> plan cache someplace and thus must be read-only, and a planstate tree,
> which contains the stuff that is for this specific execution. There's
> probably some freedom to do exciting things in the planstate nodes,
> but I don't think you can tinker with the plan itself.

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.

We'd probably want to move the join nodes into a separate ExecInitJoin()
function and do the JoinCanBeSkipped() and NonSkippedJoin() node in the
generic code.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2014-12-03 16:45:28 Re: Removing INNER JOINs
Previous Message Stephen Frost 2014-12-03 16:20:09 Re: On partitioning