Re: Removing INNER JOINs
От | Robert Haas |
---|---|
Тема | Re: Removing INNER JOINs |
Дата | |
Msg-id | CA+TgmoZcQVHq+QzJqzzotDMADZ4QxxUs=km98zG_HZrq92uXdA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Removing INNER JOINs (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Removing INNER JOINs
|
Список | pgsql-hackers |
On Wed, Dec 3, 2014 at 10:56 AM, Andres Freund <andres@2ndquadrant.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@gmail.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
В списке pgsql-hackers по дате отправления: