Julian> In particular, the ability to represent cyclic graphs is a feature
You are right. However, I'm sure "infinite planning time" does not look like a feature. Do you have suggestions to tackle this "infinite planning time" issue? What bothers me is you decline both of my approaches while you don't suggest your alternatives. My approaches were: 1) "Forbid cyclic graphs (except abstract converters)". The approach is to avoid adding a new rel to the cluster in case it creates a cycle. The nice thing is it completely eliminates the possibility of cycles. The bad thing is cycle detection is resource consuming. For each added rel it requires to walk the parent tree which might be O(N). 2) Make cross-convention rels less common. In other words, avoid the cases when FilterMergeRule fires for EnumerabelFilter(EnumerableFilter(..)) and converts that into a LogicalFilter. Both approaches improve Travis build time noticeably (the improvement is pretty much the same). PS. It is quite sad that the pattern of CALCITE-2593 is repeated: there's a user-facing bug, there's a workable solution that passes all the tests, you decline it yet provide no alternatives. Vladimir
