You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here, the GetV's query params contains all vertex types, which will involve extra unnecessary computation in Runtime (to check if the expanded vertices satisfy the constraints in query param).
However, this seems common in Gremlin queries (users may not always query like g.V().hasLabel("PERSON").out("KNOWS").hasLabel("PERSON").count()). Try to optimize such cases.
The text was updated successfully, but these errors were encountered:
…n `GetV` has imprecise types (#3804)
<!--
Thanks for your contribution! please review
https://github.com/alibaba/GraphScope/blob/main/CONTRIBUTING.md before
opening an issue.
-->
## What do these changes do?
<!-- Please give a short brief about these changes. -->
As titled. This pr:
1. Fix a bug in `ExpandGetVFusionRule`. For example, assume we have edge
types of `person-likes-comment`, `person-likes-post`,
`person-knows-person` in schema. Then in queries, if we want to expand
`person-likes-comment`, we would generate a
`Expand(likes)+GetV(comment)` (before this fix, we generate a
`Expand(likes)` only, which is a bug); And if we want to expand
`person-knows-person`, we simply generate a `Expand(knows)`.
2. Optimize cases when the types in GetV is imprecise, to avoid
unnecessary filtering in Runtime.
## Related issue number
<!-- Are there any issues opened that will be resolved by merging this
change? -->
Fixes#3732#3802
---------
Co-authored-by: Xiaoli Zhou <yihe.zxl@alibaba-inc.com>
Is your feature request related to a problem? Please describe.
Currently, in gremlin queries, the type infer may not be precise (for the operators those are not in
match()
) in GOpt.For example,
The query plan looks like (we focus on the types here, and omit most fields in the plan):
Here, the
GetV
's query params contains all vertex types, which will involve extra unnecessary computation in Runtime (to check if the expanded vertices satisfy the constraints in query param).However, this seems common in Gremlin queries (users may not always query like
g.V().hasLabel("PERSON").out("KNOWS").hasLabel("PERSON").count()
). Try to optimize such cases.The text was updated successfully, but these errors were encountered: