On Wed, Oct 5, 2016 at 9:42 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> We could prevent the crash by passing input_rel->relids to >> fetch_upper_rel() in create_grouping_path() as seen in the attached >> patch. > > I think this is fundamentally wrongheaded. If we go that route, > the only valid relids for any upper path would be the union of all > baserel RTIs, ...
Hmm, but this is only true if the upper steps are always done last. Hackers on this list have been hoping to reorder joins with aggregates since at least 2008 - probably sooner, but that's when I started reading this mailing list. A simple example is: SELECT order_line.order_id, order.customer_id, SUM(order_line.amount) FROM order_line, order WHERE order_line.order_id = order.order_id GROUP BY 1,2; Doing the aggregation step first is likely to be much faster than doing the join first here, unless of course order_line.order_id = order.order_id turns out to be highly selective. Or if there were an additional WHERE condition on the order table then it gets much less obvious which way is better. In any event, I assume we want to eventually be able to cost it out both ways and pick the cheaper one. This doesn't necessarily mean that the set of relids couldn't be used as you suggest, but if we supported this kind of thing then it wouldn't be true that "the only valid relids for any upper path would be the union of all baserel RTIs". Have you thought about this case? How would you propose that it be handled in the framework you have in mind? -- 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