Hi all, I'd like to share an article that may be of interest here, since it is about profiling the Calcite planner:
The flame graph was wrong by 57×. So I'm building a profiler. https://minogin.com/the-flame-graph-was-wrong-by-57x-so-im-building-a-profiler/ In my workload, ConverterRule.onMatch took about half of the planning time. A stack-sampling flame graph put EnumerableMergeJoinRule at 0.81% of samples, while measuring per rule gave about 46% of planning time. About twenty rules inherit onMatch without overriding it, so the stack frames can't tell them apart, and the expensive part of each firing (transformTo and the re-registration that follows) runs after convert returns, under the base class frame. This is not a bug report: the workload had nothing sorted for merge join to exploit, so it says nothing against the rule itself. But it may be useful to anyone profiling planner performance with stack-based tools. Best regards, *Andrey Minogin* Software architect minogin.com
