On Wed, Oct 5, 2016 at 9:42 AM, Tom Lane <tgl@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
