On Wed, May 13, 2015 at 10:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > For the reasons I mentioned, I'd like to get to a point where > subquery_planner's output is Paths not Plans as soon as possible. But the > idea of coarse representation of steps that we aren't trying to be smart > about might be useful to save some labor in the short run. > > The zero-order version of that might be a single Path node type that > represents "do whatever grouping_planner would do", which we'd start to > break down into multiple node types once we had the other APIs fixed.
So, getting back to this part, what's the value of returning a list of Paths rather than a list of Plans? It seems that, in general terms, what we're trying to do is delay performing some of the work, so that we can generate several candidates relatively inexpensively and decide only later which one to turn into a Plan. What's not entirely clear to me is which parts of the work we're trying to delay. For example, target lists are normally computed when paths are converted to plans, but for the higher-level plan nodes adding by grouping_planner, the path list is typically just passed in. So would the new path types be expected to carry target lists of their own, or would they need to figure out the target list on the fly at plan generation time? One thing that seems like it might complicate things here is that a lot of planner functions take PlannerInfo *root as an argument. But if we generate only paths in grouping_planner() and path-ify them later, the subquery's root will not be available when we're trying to do the Path -> Plan transformation. Presumably that means anything we need from the PlannerInfo has to be dug out and saved in the path. I think grouping_planner() is badly in need of some refactoring just to make it shorter. It's over 1000 lines of code, which IMHO is a fairly ridiculous length for a single function. -- 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
