Re: upper planner path-ification

On Wed, May 13, 2015 at 10:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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