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. I'm inclined
to think that we need to make a start on this in whatever way is
simplest, and then refine it later. Adding tlists to (some?) paths
might not be the most beautiful way to get there, but there's a lot of
important stuff piling up behind making some kind of a start on this
refactoring, and we can't just keep postponing all of that stuff
indefinitely. Or if we do, the project as a whole will be worse off
for it, I think.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
