On Wed, May 13, 2015 at 10:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Both of those are problems all right, but there is more context here.
Thanks for providing the context. >> I'm inclined to think that it would be useful to solve the first >> problem even if we didn't solve the second one right away (but that >> might be wrong). As a preparatory step, I'm thinking it would be >> sensible to split grouping_planner() into an outer function that would >> handle the addition of Limit and LockRows nodes and maybe planning of >> set operations, and an inner function that would handle GROUP BY, >> DISTINCT, and possibly window function planning. > > 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. The problem I'm really interested in solving is gaining the ability to add additional aggregation strategies, such as letting an FDW do it remotely, or doing it in parallel. It seems to me that your proposed zero-order version of that wouldn't really get us terribly far toward that goal - it would be more oriented towards solving the other problems you mention, specifically adding more intelligence to setops and allowing parameterization of subqueries. Those things certainly have some value, but I think supporting alternate aggregation strategies is a lot more interesting. -- 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
