Robert Haas <robertmh...@gmail.com> writes:
> 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.
> 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.
Clearly we'd like to get to both goals. I don't see the "zero order"
design as something we'd ship or even have in the tree for more than
a short time. But it might still be a useful refactorization step.
In any case, the key question if we're to have Paths representing
higher-level computations is "what do we hang our lists of such Paths
off of?". If we have say both GROUP BY and LIMIT, it's important to
distinguish Paths that purport to do only the grouping step from those
that do both the grouping and the limit. For the scan/join part of
planning, we do this by attaching the Paths to RelOptInfos that denote
various levels of joining ... but how does that translate to the higher
level processing steps? Perhaps we could make dummy RelOptInfos that
correspond to having completed different steps of processing; but I've
not got a clear idea about how many such RelOptInfos we'd need, and
in particular not about whether we need to cater for completing those
steps in different orders.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
