[
https://issues.apache.org/jira/browse/CALCITE-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14503490#comment-14503490
]
Julian Hyde commented on CALCITE-688:
-------------------------------------
I presume that you will want this in Hive 1.2. I don't think we can patch
Calcite in time for that. So for now let's focus on reviewing the patch. We can
get it checked in with a test case at our leisure. I presume that you can
create a copy of the rule in Hive that uses a patched version of splitCondition.
Do you have an example query that causes this?
The logic would be easier to understand and maintain if you could express it in
terms of set-theory operations on bit sets, rather than the low-level
nextSetBit operations. You could create a bit set that represents all of the
fields of a particular input, using ImmutableBitSet.range(int, int), then
intersect it with the bit sets of the conditions.
I ran the full test suite including integration tests, and the patch does not
break anything. Therefore I think it is good for your purposes. But before I
accept this patch I will need a test case, and refactoring in terms of set
operations.
> splitCondition does not behave correctly when one side of the condition
> references columns from different inputs
> ----------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-688
> URL: https://issues.apache.org/jira/browse/CALCITE-688
> Project: Calcite
> Issue Type: Bug
> Reporter: Jesus Camacho Rodriguez
> Assignee: Jesus Camacho Rodriguez
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
