Starrocks v3.1.0 decimal 类型where 查询结果不正确

【详述】Starrocks v3.1.0 where 过滤结果不正确。
【背景】在做starrocks v3.1.0 升级测试,发现和 v3.0.x 系列查询结果不一致,影响正常的业务
【业务影响】decimal 查询结果不对,影响正常的业务
【StarRocks版本】 3.1.0-1778465
【集群规模】例如:1fe+3be(fe与be独立部署)
【机器信息】CPU虚拟核/内存/网卡,例如:32C/128G/千兆
【附件】

1.建一个测试表,如下是建表语句:

create table sr_tmp_test (
    id  bigint NOT NULL,
    v2  tinyint NULL,
    v1  DECIMAL(12, 4) DEFAULT "10.5"
) PRIMARY KEY (id)
DISTRIBUTED BY HASH(id)
PROPERTIES (
    "replication_num" = "3",
    "enable_persistent_index" = "true"
);

2. 插入一下测试数据

insert into sr_tmp_test (id, v1, v2) values (1, 12.345, 0), (2, 12.3450, 0), (3, 12.3000, 0);

3. 使用starrocks v3.0.3 fe5e3a1 查询结果如下:

select  count(distinct id) from sr_tmp_test where v1='12.345';
-- result: 2
select  count(distinct id) from sr_tmp_test where v1='12.3450';
-- result: 2
select  count(distinct id) from sr_tmp_test where v1=12.345;
-- result: 2
select  count(distinct id) from sr_tmp_test where v1=12.3450;
-- result: 2

以上结果,是符合业务预期的。

4. 使用starrocks 3.1.0-1778465 查询结果如下:

select  count(distinct id) from sr_tmp_test where v1='12.345';
-- result: 0
select  count(distinct id) from sr_tmp_test where v1='12.3450';
-- result: 2
select  count(distinct id) from sr_tmp_test where v1=12.345;
-- result: 2
select  count(distinct id) from sr_tmp_test where v1=12.3450;
-- result: 2

以上结果,第一个case 结果和 starrocks v3.0.3 结果不一致,而且也是不正确的。请问这个是不是个BUG, 预计会在哪个版本修复?

@yuchen1019 @trueeyu 求大佬们确认一下这个问题 :pray:

有测试过3.1的最新小版本吗?

还没测试过,看v3.1.1 & v3.1.2 的release note 没有提到这个bug,v3.1.2是已经修复了这个问题吗?

可以试试吗?如果还有问题的话,我们介入查下。

我看这两个pr 的修改可能跟这个问题有关系。

[BugFix] Fix decimalv2 to string different as BE
[BugFix] unify cast decimal to string between FE and BE

是的,怀疑是这个,后来修复了

我看是 2023.9.4 和 2023.9.6 (昨天) 提交了到branch-3.1 的,我等一等新的 小版本 v3.1.3 发布后,然后我升级验证一下

刚升级到 v3.1.3-384ba23,目前看起来问题没有修复,下面是最新的测试结果


select count(distinct id) from sr_tmp_test where v1=‘12.345’;
– result: 0
select count(distinct id) from sr_tmp_test where v1=‘12.3450’;
– result: 2
select count(distinct id) from sr_tmp_test where v1=12.345;
– result: 2
select count(distinct id) from sr_tmp_test where v1=12.3450;
– result: 2

我用你这个测试表和数据试了一下,还真是。。目前是3.1.2-4f3a2ee版本。
插入表后是
image
select count(distinct id) from sr_tmp_test where v1=‘12.345’;
– result: 0
select count(distinct id) from sr_tmp_test where v1=‘12.3450’;
– result: 2
这两个结果跟表展示的确实有差异。。看来还挺严重,我还准备把生产环境迁移数据使用呢

@trueeyu 大佬,这个你确认一下是不是bug,目前看v3.1.3 还是有问题。

我测试了下,确实有问题,我们查下

尽量不要使用隐式类型转换,这个规则,我们内部再整理下。这个应该是Const类型的隐式类型转换规则,不同地方处理不一致导致的。

3.1的规则是:const能无损转decimal的转decimal,不能转的时候,大家都转varchar比较。但是判断这个Const是否能无损转Decimal的逻辑,我们内部还需要讨论下,当前是判断12.3450不能无损转,所以就都转成Varchar来比了,而const类型转成的varchar,后面少了个0,列Decimal类型转varchar后,后面有0

我们现在先在业务层面上根据字段类型做转换。 后面 v3.1.x 的后续的小版本,会修复这个问题么? @trueeyu

这个应该短期不会修复,可能后面会已新的转换规则为准,不然会出现一些其它奇怪的问题,最好是尽量避免使用隐式类型转换。后面也有可能会加个SqlMode来选择使用哪种方式,这个内部还有争论。

这个新的PR 是解决 decimal 对比string 的问题的解决方案么? https://github.com/StarRocks/starrocks/pull/34208

是的,是解决这个问题的

要兼容的话,需要把这个开关,set成false。可以兼容以前的

我们期望和 3.0.x 版本的行为保持一致就行,cbo_decimal_cast_string_strict 这个是配置是设为 true 还是false ?