Hi all, Yesterday we had a Hangout's chat with Vladimir in an attempt to advance a bit this discussion and converge to a solution. We went over various things but more importantly we emphasised on
the fact that rule operands might be in different conventions which is the root cause of CALCITE-2223. I will try to summarise what we discussed below (Vladimir feel free to add things if I omitted something important). There are basically two proposals so far: i) add convention information in the RelBuilderFactory; ii) add new methods with default values in RelOptRule and/or RelOptRuleOperand. Both in principle try to achieve what Julian defined as "single-convention" rules. Both solutions break backward compatibility and may require changes in projects using Calcite. In proposal (i) the changes might be more localized but the Convention information seems a bit off-place in the RelBuilderFactory. In proposal (ii) the changes will propagate to rules which need to match operands in different conventions. Is anybody in favor of either (i) or (ii) ? Στις Τρί, 5 Φεβ 2019 στις 10:35 π.μ., ο/η Vladimir Sitnikov < [email protected]> έγραψε: > 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 >
