On Thu, Sep 17, 2015 at 5:19 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Passing array offsets sounds brittle to me.
How would this case be any different from other places in the planner
where we already do exactly that? For example, RTIs.
> It would screw up any attempts to post-process the plans. Later enhancements
> seem certain to break that scheme.
I'm proposing to this very late in plan generation precisely for this
reason. I think it would be quite difficult to post-process the plans
after the planner is completely through with them. I've never heard
of anyone wanting to do that, but even if someone did, they'd still be
fine as long as they only deleted nodes or moved them around in the
tree. If someone wanted to do surgery on a plan to create new nodes,
they would need to set the ID field properly, but that's no harder
(and probably for the most part quite a bit easier) than setting all
the other fields in the Plan correctly. So I'm not seeing the
problem.
> It also assumes that all actors have access to a single memory structure
> that describes everything.
Our planner assumes that in general. How is this case different?
> Hopefully we are working on a parallel query system that will work intranode
> as well as across nodes, so access to memory should not be assumed.
Currently, the only method we have for accessing data on another node
is FDWs. When you access data via an FDW, there is both a local plan
(constructed by the local PostgreSQL) and perhaps a remote plan
(depending on what the FDW is accessing). The local plan is
accessible via local memory, and the remote plan doesn't need to be.
What I'm talking about here doesn't change any of that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
