[
https://issues.apache.org/jira/browse/CALCITE-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16594129#comment-16594129
]
Julian Hyde commented on CALCITE-2271:
--------------------------------------
I don't think we want to re-use variables with underscore prefix.
I also don't think we should be doing data-flow analysis. (Even though it's a
lot of fun.) Tools like LLVM (and indeed the JIT) are much better at data-flow
analysis than we could ever be. So let's lean on them. If we want to generate
super-efficient code, I would like to leverage
[Gandiva|https://github.com/dremio/gandiva] (which has an efficient memory
model and generates LLVM).
> Join of two views with window aggregates produces incorrect results or NPE
> --------------------------------------------------------------------------
>
> Key: CALCITE-2271
> URL: https://issues.apache.org/jira/browse/CALCITE-2271
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.16.0
> Reporter: Alexey Makhmutov
> Assignee: Julian Hyde
> Priority: Major
>
> This is a continuation of CALCITE-2081. The problem wasn't really solved in
> scope of that ticket:
> # It produces incorrect results, even in the unit-test which was included
> into the fix (function last_value(empid) shouldn't produce NULL in such
> query).
> # NPE is still present for more complex queries with joined window functions
> (e.g. if window functions with the same name are used in both part of the
> join).
> Here is the example of the query, which produces NPE in 1.16.0:
> {code:sql}
> select
> t1.l, t1.key, t2.key
> from
> (
> select
> dense_rank() over (order by key) l,
> key
> from
> unnest(map[1,1,2,2]) k
> ) t1
> join
> (
> select
> dense_rank() over(order by key) l,
> key
> from
> unnest(map[2,2]) k
> ) t2 on (t1.l = t2.l and t1.key + 1 = t2.key){code}
> The problem is still the same - windows produces several declarations with
> non-unique names, which are then incorrectly merged in BlockBuilder.append
> method (declaration name substitution conflicts with optimization logic).
> Two variables were fixed in scope of CALCITE-2081 - 'prevStart' and
> 'prevEnd', but other variables are still non-unique: result and state
> variables (aXwY and aXsYwZ which cause NPE during initialization) and 'list'
> variable (causing wrong results as both aggregates are storing results into
> the same variable).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
