Re: Removing INNER JOINs - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Removing INNER JOINs
Date
Msg-id 20141203150226.GZ3342@tamriel.snowman.net
Whole thread Raw
In response to Re: Removing INNER JOINs  (Atri Sharma <atri.jiit@gmail.com>)
Responses Re: Removing INNER JOINs  (Stephen Frost <sfrost@snowman.net>)
Re: Removing INNER JOINs  (Atri Sharma <atri.jiit@gmail.com>)
List pgsql-hackers
* 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?

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

pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: tracking commit timestamps
Next
From: Stephen Frost
Date:
Subject: Re: Removing INNER JOINs