Hi Vladimir >From the flame graph, the most time is wasted in "getRelList", I didn't see "getRelList().contains(...)" takes time, maybe it's not cost performance as we thought, if you do worry about it, I can store RelSubset#rels in Set.
Vladimir > It would be great to resolve those cases, however, until the cases are resolved (never?),", >From the flame graph, we can see actually ProjectMergeRule takes the most time and the alternate rels do huge, my point is we can take a look to see if it is reasonable(and the case in pull/2283), not mean to reslove all those cases. Regards! Aron Tao Vladimir Sitnikov <[email protected]> 于2020年12月3日周四 下午5:48写道： 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
