On Mon, May 18, 2015 at 2:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I don't know, but it seems like this might be pulling in the opposite
>> direction from your previously-stated desire to get subquery_planner
>> to output Paths rather than Plans as soon as possible.
>
> Sorry, I didn't mean to suggest that that necessarily had to happen right
> away.
>
> What we do need right away, though, is *some* design for distinguishing
> Paths for the different possible upper-level steps. I won't cry if we
> change it around later, but we have to have something to start with.
That sounds good to me.
> So for the moment, let's assume that we still rigidly follow the sequence
> of upper-level steps currently embodied in grouping_planner. (I'm not
> sure if it even makes sense to consider other orderings of those
> processing steps, but in any case we don't need to allow it on day zero.)
> Then, make a dummy RelOptInfo corresponding to the result of each step,
> and insert links to those in new fields in PlannerInfo. (We create these
> *before* starting scan/join planning, so that FDWs, custom scans, etc, can
> inject paths into these RelOptInfos if they want, so as to represent cases
> like remote aggregation.) Then just use add_path with the appropriate
> target RelOptInfo when producing different ways to do grouping etc.
>
> This is a bit ad-hoc but it would be a place to start.
>
> Comments?
That sounds reasonable, but I think the key thing is to nail down what
the new Path types are going to look like. If we know that, then
rearranging grouping_planner becomes a matter of adjusting things
piece by piece for the new data structures. Or at least I think it
does.
I think it would also be an excellent idea to split each of those
"upper level steps" embodied in grouping_planner into its own
function.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company