tidb 4.0.1,tispark 2.3.0-rc.1,限定条件读取tikv,返回数据集过大,好像没有用到过滤条件

我们有几张表是按照如下规则创建的(对某列取crc32 % 9999做为伪分区字段,并且有一个自动填充的时间字段):

我们的读取语句为:select * from table where primary_partition >= 0 and primary_partition < 10000 and last_modify_time > ‘2020-06-22 14:34:19’ 所有分区大约1.2亿数据,时间过滤之后就很少了也就10几万数据。
在tidb3.x,tispark 2.1时,这样完全没有问题;升级到最新版之后,就报oom。然后把改成:select * from table where primary_partition >= 0 and primary_partition < 5000 and last_modify_time > ‘2020-06-22 14:34:19’ 和
select * from table where primary_partition >= 5000 and primary_partition < 10000 and last_modify_time > ‘2020-06-22 14:34:19’ 分两个批次执行,就可以。
是不是新版tispark这里没有把计算推到存储底层,直接就返回了

请设置一下这个参数 spark.tispark.coprocess.codec_format=default 试试

加上这个配置也不行,还是oom,这个参数在文档上没找见,作用是啥啊?

能否

  1. 提供一下错误堆栈?
  2. 运行一下 explain select * from table where primary_partition >= 0 and primary_partition < 10000 and last_modify_time > ‘2020-06-22 14:34:19’ 看下执行计划?
  3. 试一下 select * from table where primary_partition >= 0 and primary_partition < 10000 and last_modify_time > timestamp ‘2020-06-22 14:34:19’

文档已添加

tikv本身没有异常,spark这里报了个没啥价值的信息:

执行计划如下:

tispark 2.1版本正常。到了新版就不行了。

改写成这样可以运行吗?

select * from table where primary_partition >= 0 and primary_partition < 10000 and last_modify_time > timestamp ‘2020-06-22 14:34:19’

1赞

测试了,这样是可以的。我看了执行计划都不一样。

我这个article_id是有索引的,新版tispark也不会走索引了吗?

这是另外一个问题吗?可以再开一个issue,提供一下schema信息

schema也是我开始的那种。

能提供一下 tidb 的执行计划吗?

另外这个原因是什么? tispark 2.3改了处理方式?类型不匹配要取回来然后转换成过滤条件类型,在比对?

这个和tispark的版本没关系,spark没有做类型的隐式转换,需要在字符串前面加上 timestamp

不是吧,我们用tispark 2.1版本就可以啊

请先通过tidb运行一下

analyze table ok_chi.perio_artical;

然后再通过tispark运行一下 explain

可以运行意味着没有oom,并不能表示字符串被隐式转换成了timestamp,并下推

就是说啊,完全一样的处理逻辑,在tispark 2.1是可以,没有任何报错;在tispark 2.3就不行了,就oom了:cold_sweat:

方便的话能否比对一下 tispark 2.1 时候的 explain 结果和现在的结果有何区别?