Re: Removing INNER JOINs

On 12 January 2015 at 15:57, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Jan 8, 2015 at 6:31 AM, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > I'd be keen to know what people's thoughts are about the
> nodeAlternativePlan
> > only surviving until the plan is initialised.
>
> I find it scary, although sometimes I am easily frightened.
>
>
Ok remember I'm not actually modifying the plan like I was in the earlier
version of the patch. The Alternative Plan node just simply initialises the
correct plan and instead of returning it's own initialised state, it
returns the initialised state of the selected plan's root node.

I have to admit, it didn't really become clear in my head if the frenzy of
discussion above gave any sort of indication that this "Alternative plan
node" would remain and be shown in the EXPLAIN output, or the appropriate
plan would be selected during plan initialisation and the new root node
would become that of the selected plan. When I was implement what was
discussed, I decided that it would be better to choose the correct plan
during initialisation rather than transitioning through the "Alternative
plan node" for each row. As proved already on this thread, transitioning
through needless nodes adds needless executor time overhead.

Also if we kept the alternative plan node, then I think the explain would
look rather weird and frighteningly complex, as it would effectively be 2
plans in 1.

I'm actually quite happy with how simple the executor changes became. It's
far more simple and clean than the node stripping code that I had in an
earlier version. The parts of the patch that I'm concerned might raise a
few eyebrows are the changes to query_planner() as it now returns a List of
RelOptInfo instead of a RelOptInfo.

Regards

David Rowley