Re: Removing INNER JOINs - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Removing INNER JOINs
Date
Msg-id CA+U5nM+ctehxtjQxo4Se04HB=49nFMVxW_a5S1BLC4a-pEHLtQ@mail.gmail.com
Whole thread Raw
In response to Re: Removing INNER JOINs  (Atri Sharma <atri.jiit@gmail.com>)
Responses Re: Removing INNER JOINs  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On 3 December 2014 at 12:18, Atri Sharma <atri.jiit@gmail.com> wrote:

> So the planner keeps all possibility satisfying plans, or it looks at the
> possible conditions (like presence of foreign key for this case, for eg) and
> then lets executor choose between them?

I'm suggesting the planner keeps 2 plans: One with removable joins,
one without the removable joins.

You could, in theory, keep track of which tables had pending after
triggers and skip pruning of just those but that would require you to
grovel around in the after trigger queue, as well as keep a rather
large number of plans. I don't think this deserves that complexity,
since ISTM very likely we'll almost never need the full plans, so we
just make one short test to see if there is anything in the trigger
queue at all and if so skip the pruning of any joins.

The Executor already has a Result node which allows it to decide what
subnodes to execute at run time, so this is similar.

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



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: tracking commit timestamps
Next
From: Etsuro Fujita
Date:
Subject: Re: inherit support for foreign tables