случай?
create table test1 (a Float32, b UInt32 ) engine = MergeTree order by a ;
insert into test1 values (0.1,1), (0.2,2);
select * from test1 where a > 0;
0 rows in set. Elapsed: 0.064 sec.
похоже баг оптимизатора. Оно сначала 0 приводит к целому, и смотрит потом, что попадает в подходящие целые, а они с 1 начинаются. Key condition: (column 0 in [1, +inf)) можно обойти так: where a > 0.0
не говорите ерунды попробуйте сделать select 0.1 + 0.1 union all select 0.1 + 0.1 + 0.1;
и при чем тут это?
при том, особенности обработки fp на процессорах x86
Ну проверьте в новой версии и пишите багу на гитхаб
покажите мне процессов, на котором 0.1 во float32 будет не больше 0. Там сравнивают a > 0, где a = 0.1 и a = 0.2
Да, согласен, толком не прочитал. Это действительно баг, но не оптимизатора.
а если 0.5 ? или 0.6?
версия 22.1 Похоже на две баги - одна с оптимизатором, как верно предположили выше. Вторая про равенство флоатов, вне зависимости от индекс-не индекс: create table test1 (a Float32, b Float32 ) engine = MergeTree order by a ; insert into test1 values (0.1,0.1), (0.2,0.2); select * from test1 where b = 0.1; <ничего не найдено> select count() from test1 where a > 0; <ничего не найдено> select count() from test1 where a > 0.0; 2 на гитхабе две заводить или там можно в одну?
Обсуждают сегодня