Re: Removing INNER JOINs

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, 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: 2015-01-08 11:31:45
Message-ID: CAApHDvpn=A+vXgu2jFiswn_RtbOspdqMVpBbkMhpCHrftUgAMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10 December 2014 at 23:04, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

>
> The bulk of my changes are in allpaths.c, planmain.c and planner.c. The
> critical change is query_planner() now returns a List instead of
> a RelOptInfo. I wasn't quite sure how else to handle this. Please also
> notice the change to make_one_rel(). This function is now called twice if
> remove_useless_joins() found 1 or more INNER JOINs to be possibly
> removable. in remove_useless_joins() the rels are not marked as
> RELOPT_DEADREL like they are with LEFT JOINs, they remain as
> RELOPT_BASEREL, only they have the skipFlags to mark that they can be
> removed when there's no FK triggers pending. A flag on PlannerGlobal is
> also set which will later force make_one_rel() to be called twice. Once for
> the join removal plan, and once for the "All Purpose" plan. query_planner()
> then returns a list of the RelOptInfos of those 2 final rels created by
> make_one_rel(). All the processing that previously got done on that final
> rel now gets done on the list of final rels. If there's more than 1 in that
> list then I'm making the root node of the plan an "AlternativePlan" node.
> On init of this node during execution time there is some logic which
> chooses which plan to execute. The code here just calls ExecInitNode() on
> the root node of the selected plan and returns that, thus skipping over the
> AlternativePlan node, so that it can't be seen by EXPLAIN or EXPLAIN
> ANALYZE.
>

I had left the previous patch a bit unpolished.
In the attached I've created a new source file for nodeAlternativePlan and
also performed various cosmetic cleanups.

I'd be keen to know what people's thoughts are about the
nodeAlternativePlan only surviving until the plan is initialised.

Regards

David Rowley

Attachment Content-Type Size
inner_join_removals_2015-01-09_1dd478e.patch application/octet-stream 112.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2015-01-08 11:42:59 Re: Parallel Seq Scan
Previous Message Deepak S 2015-01-08 09:41:21 List of table names of a DB