Go statement query slows down when the number of outgoing edges increases

[jordandandan]

问题：
语句：go from 0 over belongs yield $$.user.deviceId as deviceId | limit startOffset, size
每次查询size为1万条
user节点100万时每次查询为秒级别，当增大到1000万时需要1～2分钟，耗时是否正常，如何优化

[jordandandan]

而且查询的时候内存飙升，并且查询完内存不会释放，是否有方法不取全部数据再分页

[jordandandan]

[yixinglu]

问题：
语句：go from 0 over belongs yield $$.user.deviceId as deviceId | limit startOffset, size
每次查询size为1万条
user节点100万时每次查询为秒级别，当增大到1000万时需要1～2分钟，耗时是否正常，如何优化

看这里的查询是从单个 user 出发找 device，这个语句应该跟整个数据量没有关系才对。因为每次查询到的点边只跟起点有关，与总的 user 数量无关。

内存管理是由 JEMalloc 库完成的，不一定所有使用完的内存会立即还给操作系统，有些内存可以给下次的 query 使用，不用再向系统申请新的内存。

能否根据 deviceId 通过 WHERE 过滤来达到你的要求，比如：

go from 0 over belongs WHERE belongs._dst >= 100 AND belongs._dst < 200 yield $$.user.deviceId as deviceId

[jordandandan]

这样查询满足需求，但是耗时仍然是分钟级别，您之前提到的：“因为每次查询到的点边只跟起点有关，与总的 user 数量无关“，这里测试的是从起点到1000万个终点每个点都有一条边，相当于有1000万条边；此外测试了：belongs._dst >= 0 AND belongs._dst < 100和belongs._dst >= 0 AND belongs._dst < 10000两种条件的耗时 ，结论为查询100个与10000个查询耗时都是1分钟，感觉是和整体的边的数量有关

[yixinglu]

这样查询满足需求，但是耗时仍然是分钟级别，您之前提到的：“因为每次查询到的点边只跟起点有关，与总的 user 数量无关“，这里测试的是从起点到1000万个终点每个点都有一条边，相当于有1000万条边；此外测试了：belongs._dst >= 0 AND belongs._dst < 100和belongs._dst >= 0 AND belongs._dst < 10000两种条件的耗时 ，结论为查询100个与10000个查询耗时都是1分钟，感觉是和整体的边的数量有关

刚看了下类似的语句的执行计划，目前还是没能够把 where 中的 filter 下推到存储层中，所以这里的 100 和 10000 的执行结果差别不大。这块的优化正在开发过程中。

等 vesoft-inc/nebula-graph#1263 PR 合入之后， @czpmango 看看是否可以提供一个 OptRule 解决一下这个下推的问题。

[CPWstatic]

This case could be written in match. We will work on the performance of match on the next roadmap.