[
https://issues.apache.org/jira/browse/CALCITE-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16738586#comment-16738586
]
Julian Hyde commented on CALCITE-2635:
--------------------------------------
I agree, https://arewefastyet.com would be awesome. But we've been talking for
years about performance regression tests and no one has done anything. Whatever
approach we take, we will want to annotate in the code which tests are
considered performance-critical. Then we can gather performance of those tests
over time, on the same hardware, and look for trends/variance.
The variance of a single-threaded test between the slowest and fastest hardware
is no more than 5x, whereas the variance between a good and bad algorithm can
be several orders of magnitude. So it's not too difficult to write a useful
test.
> getMonotonocity is slow on wide tables
> --------------------------------------
>
> Key: CALCITE-2635
> URL: https://issues.apache.org/jira/browse/CALCITE-2635
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Gian Merlino
> Assignee: Gian Merlino
> Priority: Major
> Labels: performance
>
> RelOptTableImpl's getMonotonocity does an indexOf on
> {{rowType.getFieldNames()}}, which is O(N) in the number of fields.
> IdentifierNamespace calls getMonotonicity once for every field in the table
> namespace, so it becomes O(N^2) in the number of fields. We observed 2-4
> second query planning times with a table that had 18,000 columns, reduced to
> about 150ms after patching getMonotonicity to be O(1) in the number of fields.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
