Re: upper planner path-ification
Andrew Gierth <andrew@tao11.riddles.org.uk>
From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
"pgsql-hackers\@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2015-05-17T15:41:17Z
Lists: pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: >> If there's interest, we could do that specific task as part of >> adding hashagg support for grouping sets (which would otherwise make >> it even longer), or as preparatory work for that. Tom> I think that refactoring without changing anything about the way Tom> it works will be painful and probably ultimately a dead end. As Tom> an example, the current_pathkeys local variable is state that's Tom> needed throughout that process, so you'd need some messy notation Tom> to pass it around (unless you stuck it into PlannerRoot, which Tom> would be ugly too). But that would go away in a path-ified Tom> universe, because each Path would be marked as to its output sort Tom> order. More, a lot of the code that you'd be relocating is code Tom> that we should be trying to get rid of altogether, not just Tom> relocate (to wit all the stuff that does cost-based comparisons of Tom> alternatives). Tom> So I'm all for refactoring, but I think it will happen as a natural Tom> byproduct of path-ification, and otherwise would be rather forced. Hrm, ok. So for the near future, we should leave it more or less as-is? We don't have a timescale yet, but it's our intention to submit a hashagg support patch for grouping sets as soon as time permits. -- Andrew (irc:RhodiumToad)