On Wed, May 13, 2015 at 10:27 PM, Tom Lane <tgl@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
