xiedeyantu commented on PR #4322: URL: https://github.com/apache/calcite/pull/4322#issuecomment-2826600485
> > I think it is a good design principle to have each rule be as simple as possible, and not do work that another rule can do. However, there is a balancing act in practice, because the complexity of the search process is exponential in the number of rules that can be applied at each step, so there may be performance benefits in having a rule perform optimizations that it _knows_ for sure are beneficial - rather than hoping the optimizer will guess what to do next. > > I agree on your statement, I have baked into rules some "transformations" (e.g., predicate simplifications despite there is a rule to do that) when we knew we had to do it. In this case, `FILTER_MERGE` rule is part of the standard rule set in Calcite and it's a "cheap" rule, that's why I am more inclined to avoid merging filters in this rule, but I am happy to discuss trade-offs if you think otherwise. I think you've convinced me. I just need to focus on the issues I should be dealing with. -- 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]
