This message was deleted.

Dear Sandeep, welcome to the NebulaGraph community 🙂 Will come back to you seen, I am on a meeting now, you could have a look at index related doc/post first, I will come back with more explanation later after the meeting. • https://docs.nebula-graph.io/3.2.0/3.ngql-guide/14.native-index-statements/ • https://www.siwei.io/en/nebula-index-explained/

Hi @wey. Thanks for the quick reply and sharing the reference links. I'll check them out. (To provide more context on my query: I'm using Nebula studio and I need all the available nodes and edges to be displayed as connected graph representation)

Hi @Sandeep Sorry for the late follow-up. The Long version comes: In NebulaGraph, `(m)-[e]->(n) RETURN m,n,e limit 10`was not allowed by complaining cannot be pushed down is due to we forbidden queries introducing full scan of data. By full scan, I am referring to this pattern didn’t specify any vertex or edge types, thus the limit cannot be pushed down to the storage side when scanning data. More specifically, in graphD, it will construct an execution plan to starting from scan of vertex or edge (or index is there is any), then get neighbors, etc…, the case without any tag/edge type cannot be efficiently pushdown (as nebulaGraph was designed schemaFul to enable high perf for large scale data). Thus the mind module in NebulaGraph with Cypher to sample node/edges could be: When no indexes were created(on tag or edge):

match ()-[e:follow|:serve]->() return e limit 100

or

match (v:player) return v limit 10

Where we put all edge types and tags where it could scan edges with limit/sample pushdown. Or if we have created indexes on any tag or edge, queries like

when there is index on tag: player

match (v:player)-[e:follow|:serve]->(v1) return v,e,v1

Hi @wey. Sorry for the late response. Thanks a lot for the detailed explanation.