[
https://issues.apache.org/jira/browse/CALCITE-6593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885093#comment-17885093
]
Julian Hyde commented on CALCITE-6593:
--------------------------------------
[~rrueda], I agree. If the performance is significantly better for
tables/queries with more than N columns, let's make it the default. (And let's
run some performance benchmarks to figure out the break-even point for N.)
Invoking the code in the normal case (not just very wide tables) will make it
more reliable. Can you please log a Jira case for that work?
That also makes the Flink code-splitter task completely separate from this.
> NPE when outer joining tables with many fields and unmatching rows
> ------------------------------------------------------------------
>
> Key: CALCITE-6593
> URL: https://issues.apache.org/jira/browse/CALCITE-6593
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Rodrigo Rueda
> Assignee: Ruben Q L
> Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.38.0
>
>
> The fix for CALCITE-3094 started generating the following code for a join
> when the resulting field count is >= 100.
> {code:java}
> public Object[] apply(Object[] left, Object[] right) {
> Object[] outputArray = new Object[102];
> System.arraycopy(left, 0, outputArray, 0, 94);
> System.arraycopy(right, 0, outputArray, 94, 8);
> return outputArray;
> } {code}
> But left or right might be null if one of the sides of the join is empty,
> which leads to a NPE:
> {code:java}
> java.lang.NullPointerException
> at java.base/java.lang.System.arraycopy(Native Method)
> at Baz$3.apply(Unknown Source)
> at Baz$3.apply(Unknown Source)
> at Baz$3.apply(Unknown Source)
> at
> org.apache.calcite.linq4j.EnumerableDefaults$12$1.current(EnumerableDefaults.java:2078)
> at Baz$4$1.current(Unknown Source) {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
