JiaTao Tao, thanks for the details! JiaTao Tao> found. Without pull/2222, some cases will fail due to "There are not enough JiaTao Tao> rules to produce a node with desired properties: There is 1 empty subset", JiaTao Tao> the root cause is the outdated rule matches have been fired.
The comment in 2222 reads "rel has been removed from set". Does that mean VolcanoPlanner#rename results in an inconsistent state of the rels/sets? If that is the case, I would suggest moving the fix to VolcanoPlanner#rename. JiaTao Tao>2. pull/2222 itself is a positive fix, it due increase the time but the JiaTao Tao>true problem is RelSubset#getRelList, we can improve pull/2222 by JiaTao Tao>improving RelSubset#getRelList If you can make getRelList fast without losing too much time in other cases, that would be awesome. However, the current implementation of getRelList is slow, so it should be used with caution. Even if you make getRelList() a O(1) operation, it won't resolve getRelList().contains(...) That is why I'm inclined that 2222 should not come alone. JiaTao Tao>3. Calcite sometime will generate huge alternate rels, That is true. One of the known cases was https://issues.apache.org/jira/browse/CALCITE-2223 It would be great to resolve those cases, however, until the cases are resolved (never?), we should not rely on "the list of rules being small" or something like that. Vladimir
