对节点属性的函数结果进行过滤的逻辑是否会下推

场景如下:
有一个节点类型T,它有一个属性p是String类型;
p的值为"a,b,c,d,e";
我对p的过滤逻辑为:where size([e IN split(p, ‘,’) where e > ‘b’ | e]) > 0;

想问一下,这个处理逻辑会下推到storaged处理么?还是会在graphd处理?
explain能看出执行计划哪些在storaged执行,哪些在graphd执行吗?

@yee 这边有个 Explain 的问题呢

如何 p 是起点 tag 上的属性,虽然 where 的过滤条件比较复杂,但是只是针对该属性的操作,是应该可以下推的。

现在有没有支持下推需要 @jievince 来确认一下,如果没有看看实现的复杂度。

explain 可以打印执行计划的所有的结点,其中跟 storage 打交道的结点有 GetVerticesGetNeighbors 等结点,在这些结点上有 filter 字段来表示下推到 storage 的表达式。

profile了这个语句,对起点出发的边上属性进行带函数的过滤,逻辑也可以下推吧,但是profile的结果如下:

按照刚才你说的,GetNeighbors的filter是没有的,执行计划有专门一个filter阶段,这个是在graphd处理的吗?

你看一下 nebula-graphd.conf 中的 enable_optimizer=false 的 flag 有没有打开,现在默认优化器是关闭的,需要打开优化器才能做过滤下推。

修改配置后,需要重新启动 nebula-graphd 进程。

在实际生产环境这个开关打开与否需要有什么考虑吗?

在 GA 版本中我们考虑将其默认值改成 true,目前的优化器主要实现 RBO 的功能

[e IN split(p, ‘,’) where e > ‘b’ | e]这种表达式目前没有做下推, 但应该可以做。

1赞

可以的话建议排上日程吧,逻辑上这种过滤也适合下推,此外我们也确实有这方面的需求 :blush:

表达式下推目前在开发中哈,有新的进展我会更新帖子的哈。

从我个人角度看,点的下推意义不大,实际上也没做。无论是fetch还是go,只影响storage返回到graph的数据量。

我理解这需要看过滤率吧,如果过滤后的点或者边只有storaged获取的20%,那么相当于把80%无效的数据传到了graph,这部分传输开销其实是没有意义的

来更新下帖子,我们在这个 pr:https://github.com/vesoft-inc/nebula-graph/pull/810 里实现了 [e IN split(p, ‘,’) where e > ‘b’ | e]这种表达式的下推

1赞

浙ICP备20010487号