Re: Removing INNER JOINs

On Wed, Dec 3, 2014 at 10:56 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-12-03 10:51:19 -0500, Robert Haas wrote:
>> On Wed, Dec 3, 2014 at 4:29 AM, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>> > *** Method 1: Removing Inner Joins at planning time:
>> >
>> > *** Method 2: Marking scans as possibly skippable during planning, and
>> > skipping joins at execution (Andres' method)
>> >
>> > *** Method 3: Marking scans as possibly skippable during planning and
>> > removing redundant join nodes at executor startup (Simon's method)
>> [....]
>> > a. can we invoke the planner during executor init?
>>
>> I'm pretty sure that we can't safely invoke the planner during
>> executor startup, and that doing surgery on the plan tree (option #3)
>> is unsafe also. I'm pretty clear why the latter is unsafe: it might
>> be a copy of a data structure that's going to be reused.
>
> We already have a transformation between the plan and execution
> tree.

We do?

I think what we have is a plan tree, which is potentially stored in a
plan cache someplace and thus must be read-only, and a planstate tree,
which contains the stuff that is for this specific execution. There's
probably some freedom to do exciting things in the planstate nodes,
but I don't think you can tinker with the plan itself.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company