On Thu, Sep 17, 2015 at 5:19 PM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
