On Mon, May 18, 2015 at 2:50 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers