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