On Thu, Jan 8, 2015 at 6:31 AM, David Rowley <dgrowleyml@gmail.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.