Re: Removing INNER JOINs

* Atri Sharma (atri(dot)jiit(at)gmail(dot)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?

Right, this was one of the thoughts that I had.

> So is the idea essentially making the planner return a set of "best" plans,
> one for each condition? Are we assured of their optimality at the local
> level i.e. at each possibility?

We *already* have an idea of there being multiple plans (see
plancache.c).

> IMO this sounds like punting the planner's task to executor. Not to mention
> some overhead for maintaining various plans that might have been discarded
> early in the planning and path cost evaluation phase (consider a path with
> pathkeys specified, like with ORDINALITY. Can there be edge cases where we
> might end up invalidating the entire path if we let executor modify it, or,
> maybe just lose the ordinality optimization?)

The executor isn't modifying the plan, it's just picking one based on
what the current situation is (which is information that only the
executor can have, such as if there are pending deferred triggers).

> I agree that executor should not modify plans, but letting executor choose
> the plan to execute (out of a set from planner, of course) rather than
> planner giving executor a single plan and executor not caring about the
> semantics, seems a bit counterintuitive to me. It might be just me though.

I don't think it follows that the executor is now required to care about
semantics. The planner says "use plan A if X is true; use plan B is X
is not true" and then the executor does exactly that. There's nothing
about the plans provided by the planner which are being changed and
there is no re-planning going on (though, as I point out, we actually
*do* re-plan in cases where we think the new plan is much much better
than the prior plan..).

Thanks!

Stephen