[
https://issues.apache.org/jira/browse/CALCITE-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16659635#comment-16659635
]
Julian Hyde commented on CALCITE-2635:
--------------------------------------
We never found a good solution to performance tests. You can't set a hard
deadline, because there's inevitably noise (e.g. GC pauses) that may make a
test take 100% longer than usual.
The solution would probably be to run the test in a consistent environment over
time, discard outliers (the GC pauses) and check that the moving average of
running times stay within a range. But this is hard to orchestrate.
I therefore think we should write a junit test with the expected running time
described in a comment above the test. Developers can run it manually, and it
will be run as part of the suite. If the test starts running 100x slower
overnight maybe we will notice, and maybe we won't.
Consider creating an annotation so that we can find all performance tests:
{code}
@PerformanceTest(expectedDuration = "2s", variance = "5%")
{code}
> 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)
