1.6.0, 1.6.1, 1.6.2, 1.6.3, 1.6.4, 1.6.5, 1.6.6, 1.7.0, 1.6.7, 1.6.8, 1.6.9, 1.6.10, 1.6.11
Due to the bug of inconsistent hashing in bloom filters, when reading ORC files that have bloom filters written by old C++ clients, the bloom filters won't be used. This may results in performance regression.
drorke found that the C++ reader could incorrectly filter out some rows (RowGroup) when reading Hive generated ORC files with SearchArgument "x = value" using some special values. It only happens when Hive generates bloom filters in these files.
I finally reproduced this by using the java tool (with
ORC-1023) to generate an ORC file with bloom filters, and read it using the c++ reader. Attached the orc file (id_name_with_bloom_filters.orc). It contains 2 columns and 3 rows:
Using SearchArgument "id = 18000000000" in the C++ reader, no rows will be read out.
Looking into the codes, the Java codes use long as hash key, while the C++ codes use uint64_t as hash key. long in Java is signed so should correspond to int64_t in C++. I think this causes the issue.
In Java codes, the hash key of 18000000000 is -1097054448615658549. In the C++ codes, the hash key of it is 15298148493198126027. This results in different results in testHash().