xiedeyantu commented on PR #4585: URL: https://github.com/apache/calcite/pull/4585#issuecomment-3429254074
> > > > @asolimando I've made some adjustments. This is the best solution I can think of at the moment. Please take another look—your feedback is greatly appreciated! If you think this approach isn't suitable, we can pause for now and see if anyone in the JIRA thread can help brainstorm alternative solutions. > > > > > > > > > The updated version feels like an improvement into the right direction already, but I was wondering if we could optimize/simplify the target collation and then compare as usual? > > > For your iq query example, would it be possible to determine that `[0, 1] => [0]` for the query as well? At that point we would just need to match as we used to do, but I don't know if that's feasible > > > > > > If 0 -> 1, it can be proven that [0,1] and [0] are equivalent, so it has no impact on the query results. If performing only ORDER BY 0 affects the results, it indicates an issue with the rule implementation. Here, we only need to record the equivalent collection before optimization, and during trait satisfaction judgment, adding the [0] attribute RelSubset to the [0,1] attribute RelSubset will fulfill the overall requirement. > > What I mean is: do we need to store the original mapping if we can optimize the requested collation? > > If we could do that, we would end up with the same exact collation, we could just compare optimized with optimized directly without having to store the mapping original->optimized. Would that be possible in your opinion? If I understand correctly, it might be difficult for us to achieve. Once a RelRoot (or RelNode) enters the volcano optimizer, the property [0,1] is fixed. It can be extended through rules that satisfy the property, but it cannot be altered during the optimization process—which I believe is logical. On the other hand, without a specific logical basis (such as functional dependencies), the satisfaction of [0] by [0,1] does not hold. I think we need to address these two issues. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
