想问下在k跳的GO语句的优化规则中，为何没有加入PushFilterDownGetVerticesRule，基于何种考量呢？以及未来是否有增加该优化项的计划。
优化规则的添加是开放的，如果遇到了可以优化的场景是可以添加到规则集中的，你查询中的语句是什么样的？可否贴一下 query，我们一起看看是否可以优化？
1 个赞
GO 3 STEPS FROM “Tim Duncan” OVER like WHERE like.likeness > 90 AND $$.player.age>20 AND $^.player.age<90 yield $^.player.name, like.likeness, $$.player.name
这里是一条对nba数据集的查询语句，包含了对起点，终点，边三者的属性过滤，并输出三者各一个属性
对于这样一条语句，filter的最佳下推位置应该是：起点&&边 下推到 getNbrs算子，终点 下推到 getVertices算子中
目前的优化规则，因为缺少把filter下推到getVertices中及之下的规则，即：filter<-getVertices(w.o. filter) 到getVertices(with filter)[<-filter]（方框中的因情况而定），而无法做任何的下推操作。
这样的优化是显而易见的，但是nebula并没有这样做，是出于怎样的考量呢？
很好的建议，提了 issue 来跟踪。这个确实是可以优化的点。
没添加这条规则，也没有什么特殊的考量，可能就是还没遇到此类的优化吧。不过确实可以实现一条此类的规则，你如果有兴趣，也可以贡献一个优化给 nebula 
没有什么特殊考量的话，就可以浅尝试一下了。
1 个赞
在处理filter类型的时候，遇到了filter改写的问题，请问在Go语句的Validator中，为什么要设计这么多的rewriter呢？
虽然注释里写了是为了执行节点间的数据传递，但是用重写之前的filter形式应该也是可以完成对应的。
所以为什么要把这么多的属性条件改写为变量过滤？？不这么做会有什么问题吗？？
比如$$.player.name AS __COL_4。
这里的变量改写是为了将 parser 过来的一些表达式改写成可以运行时执行的表达式，比如 parser 过来的表达式很多都是统一化的处理为 label expression/label attribute expression，这些表达式在运行时是不能执行的，需要根据 label 具体是指的哪些变量来进行改写。
此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。