Elena Stepanova added a comment - 2018-04-08 20:35 According to cross-reference, it was happening on 10.2 as well. Then it stopped for 2 months (maybe the test was disabled?) and now it re-appears on bb-10.2-mariarocks-merge. Thus, I'm adding 10.2 to affected versions.

Sergei Petrunia added a comment - 2018-04-09 08:31 Queries right before the difference: create or replace table t1 ( id1 bigint not null , id2 bigint not null , id3 varchar (100) not null , id4 int not null , id5 int not null , value bigint , value2 varchar (100), primary key (id1, id2, id3, id4) COMMENT 'rev:cf_short_prefix' , index id2 (id2) COMMENT 'rev:cf_short_prefix' , index id2_id1 (id2, id1) COMMENT 'rev:cf_short_prefix' , index id2_id3 (id2, id3) COMMENT 'rev:cf_short_prefix' , index id2_id4 (id2, id4) COMMENT 'rev:cf_short_prefix' , index id2_id3_id1_id4 (id2, id3, id1, id4) COMMENT 'rev:cf_short_prefix' , index id3_id2 (id3, id2) COMMENT 'rev:cf_short_prefix' ) engine=ROCKSDB; ... insert t1 select (seq+9) div 10, (seq+4) div 5, (seq+4) div 5, seq, seq, 1000, "aaabbbccc" from seq_1_to_10000; insert t2 select * from t1; call bloom_start(); select count (*) from t1; count (*) A possible way this could be happening: INSERT has finished, but the table statistics was not updated yet. Then a different index isused for reading and thus bloomfitlter is not used.

Sergei Petrunia added a comment - 2018-04-09 08:36 OTOH, the column family settings are: rocksdb_override_cf_options= cf_short_prefix={prefix_extractor=capped:4}; rev:cf_short_prefix={prefix_extractor=capped:4}; bloom_end() checks if rocksdb_bloom_filter_prefix_checked > 0 . 4 bytes are index-nr, so theoretically any table access should have checked the bloom filter (or perhaps there is a primary vs secondary or covering/non-covering index difference?)

Vladislav Vaintroub added a comment - 2018-04-09 14:27 elenst yes, it was disabled, by me, in the attached commits.