Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, May 17, 2015 at 12:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Rather than adding tlists per se to Paths, I've been vaguely toying with
>> a notion of identifying all the "interesting" subexpressions in a query
>> (expensive functions, aggregates, etc), giving them indexes 1..n, and then
>> marking Paths with bitmapsets showing which interesting subexpressions
>> they can produce values for. This would make things like "does this Path
>> compute all the needed aggregates" much cheaper to deal with than a raw
>> tlist representation would do. But maybe that's still not the best way.
> 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.
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?
regards, tom lane