MATCH (v) RETURN v LIMIT n returns -1005:Storage Error: part: 40, error: E_RPC_FAILURE(-3).

[sunkararp]

Nebula version: 3.1.0

Hi @wey-gu simple below query fails with the error.

MATCH (v:Student) RETURN v LIMIT 10

Error

-1005:Storage Error: part: 40, error: E_RPC_FAILURE(-3)

There are about 10 million Student vertices in the system.

• Is my query timing out?
• If timing out, per how to resolve faq I need to extend the connection timeout of the Storage client by setting --storage_client_timeout_ms=60000 in nebula-graphd.conf file
• Where is nebula-graphd.conf file and how I set --storage_client_timeout_ms in K8S environment?
• Running below command brings up all graphd severs

show hosts

• I tried to edit nebula-cluster-graphd, but my edits are overridden by resetting graphd

kubectl edit configmap nebula-cluster-graphd -n mynamespace

[wey-gu]

For configuration change in k8s operator, please refer to: https://github.com/vesoft-inc/nebula-operator/blob/master/doc/user/custom_config.md and in case it's not doable with this, we could raise it to nebula-operator repo as a request.

MATCH (v:Student) RETURN v LIMIT 10

In This query, limit is not pushdown to storage side, thus the query is fetching all data to graphd, which is quite costly actually.

You could for now try lookup on Student yield vertex as v | limit 10 instead it'll be extremely fast :)

[Milittle]

For configuration change in k8s operator, please refer to: https://github.com/vesoft-inc/nebula-operator/blob/master/doc/user/custom_config.md and in case it's not doable with this, we could raise it to nebula-operator repo as a request.

MATCH (v:Student) RETURN v LIMIT 10

In This query, limit is not pushdown to storage side, thus the query is fetching all data to graphd, which is quite costly actually.

You could for now try lookup on Student yield vertex as v | limit 10 instead it'll be extremely fast :)

Is this limit will be supported to pushdown to sotrage, any plan? thx

[wey-gu]

• this query took about 153 seconds consuming about 16 GB; can we further refine?

Do you mean the lookup one or the match one, please? If it's the lookup one, could you help share the profile of the query?

[wey-gu]

In This query, limit is not pushdown to storage side, thus the query is fetching all data to graphd, which is quite costly actually.
You could for now try lookup on Student yield vertex as v | limit 10 instead it'll be extremely fast :)

Is this limit will be supported to push down to storage, any plan? thx

@MuYiYong do we have plans to support match limit pushdown in nebula repo, please :D

[Milittle]

I know when the tag do not have index, the match limit sentence will be pushdown to storage. but when create one index for tag, the RBO rule can not matched, so I think maybe adjust some code, it will be supported?

[hesy007]

we want to use cypher instead of lookup