[
https://issues.apache.org/jira/browse/CALCITE-6593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884580#comment-17884580
]
Rodrigo Rueda commented on CALCITE-6593:
----------------------------------------
Regarding the decision to revert this once the "code split" feature is
released, I think the CALCITE-3094 change has its own value. Assuming the
benchmark provided is correct, it's a great performance improvement for wide
tables.
In fact, I like to think what is being called the "compact code" is actually
the obvious code for joining arrays, and the current way of doing it is an
optimization for small arrays.
> 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)