[
https://issues.apache.org/jira/browse/HIVE-12945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15120275#comment-15120275
]
Gopal V commented on HIVE-12945:
--------------------------------
It is setting the bit in the bitset twice.
{code}
int n = ObjectInspectorUtils.getBucketNumber(convCols, new
ObjectInspector[]{constOI}, ctxt.getNumBuckets());
bs.set(n);
+ if (ctxt.isCompat()) {
+ int h = ObjectInspectorUtils.getBucketHashCode(convCols, new
ObjectInspector[]{constOI});
+ // -ve hashcodes had conversion to positive done in different ways
in the past
+ // abs() is now obsolete and all inserts now use & Integer.MAX_VALUE
+ // the compat mode assumes that old data could've been loaded using
the other conversion
+ n = ObjectInspectorUtils.getBucketNumber(Math.abs(h),
ctxt.getNumBuckets());
+ bs.set(n);
+ }
{code}
Once with the known good path and once with the Math.abs() path. For a +ve
hash-code that will be a no-op.
For a -ve hash-code like -15, it will be (15 % 16) vs (2147483633 % 16)
resulting in [1,15] for the bitset, as it shows up in the test-case.
> Bucket pruning: bucketing for -ve hashcodes have historical issues
> ------------------------------------------------------------------
>
> Key: HIVE-12945
> URL: https://issues.apache.org/jira/browse/HIVE-12945
> Project: Hive
> Issue Type: Bug
> Components: Tez
> Affects Versions: 2.0.0
> Reporter: Gopal V
> Assignee: Gopal V
> Priority: Critical
> Attachments: HIVE-12945.1.patch
>
>
> The different ETL pathways differed in reducer choice slightly for -ve
> hashcodes.
> {code}
> (hashCode & Integer.MAX_VALUE) % numberOfBuckets;
> !=
> Math.abs(hashCode) % numberOfBuckets
> {code}
> Add a backwards compat option, which can be used to protect against old data
> left over from 0.13.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
