Joyemang33
Joyemang33
ATApache TinkerPop
Created by Joyemang33 on 7/1/2023 in #questions
Encounter strange behaviors in "match()" step
Hello! Sorry for bothering you once again. When I further investigate the problem I post at https://issues.apache.org/jira/projects/TINKERPOP/issues/TINKERPOP-2961?filter=allopenissues. I found that the result of this query is unstable.
g.V().match(
__.as("n2").out().as("n1"),
__.as("n2").in().in().in().both().in().as("n1"),
__.as("n2").both().in().in().as("n3"),
__.as("n3").in().both().as("n2"),
__.as("n2").in().in().in().in().both().as("n4"),
__.as("n2").out().both().in().as("n4"),
__.as("n3").both().as("n4"),
__.as("n1").in().both().both().both().as("n5")
).dedup().count()
g.V().match(
__.as("n2").out().as("n1"),
__.as("n2").in().in().in().both().in().as("n1"),
__.as("n2").both().in().in().as("n3"),
__.as("n3").in().both().as("n2"),
__.as("n2").in().in().in().in().both().as("n4"),
__.as("n2").out().both().in().as("n4"),
__.as("n3").both().as("n4"),
__.as("n1").in().both().both().both().as("n5")
).dedup().count()
After creating the graph based on the statements provided in the Jira attachment, I obtained a result. Then, I deleted all the nodes and recreated the same graph. Surprisingly, when I ran the same query again, it returned a different result. This inconsistency in the query results may suggest a potential bug in the schema creation process. I would appreciate any assistance in reproducing and confirming this issue. Best regard, Joye
8 replies
ATApache TinkerPop
Created by Joyemang33 on 6/10/2023 in #questions
Are the developers of TinkerPop interested in the Performance difference on the equivalent queries?
Hi all! I was recently working on generating equivalent Gremlin queries to test TinkerGraph and then found that some of the equivalent queries had large runtime differences. For example,
g.V().match(__.as("a").has("color", eq("blue")).out().out().out().out().as("b"),
__.as("b").has("color", eq("red"))).select("b")

g.V().match(__.as("b").has("color", eq("red")).in().in().in().in().as("a"),
__.as("a").has("color", eq("blue"))).selct("b")
g.V().match(__.as("a").has("color", eq("blue")).out().out().out().out().as("b"),
__.as("b").has("color", eq("red"))).select("b")

g.V().match(__.as("b").has("color", eq("red")).in().in().in().in().as("a"),
__.as("a").has("color", eq("blue"))).selct("b")
The two queries to select nodes with the red color are equivalent; however, their running times can vary significantly. For instance, if the number of red nodes is much smaller in the first query compared to the second one, the first query may produce a large number of intermediate results while the second query avoids this. I noticed that TinkerGraph optimizes the traversal strategy at match time, which suggests that the queries in this simple example might be optimized. However, during my actual testing, I encountered some triggering test cases. Although I believe this behavior may be expected in Gremlin, I would like to reach out to the developers to inquire if they are interested in optimizing these queries further. In that case, I can share the test cases I found (which may not be as straightforward as this example, unfortunately :(, but I will try my best to reduce and simplify them ).
40 replies
ATApache TinkerPop
Created by Joyemang33 on 6/6/2023 in #questions
Question on macth step
I am wondering why the following queries return the different results:
gremlin> graph = TinkerFactory.createModern() gremlin> g=traversal().withEmbedded(graph) gremlin> g.V().match(.as("a").both().as("b").both().as("c")).count() ==>30 gremlin> g.V().match(.as("a").both().as("b").both().as("c"), __.as("a").both().as("b").both().as("c")).count() ==>48
I must admit that I have not understood the "match" step, thus I am not sure whether it is a expected behavior or an issue. It would be highly appreaciated if somebody could help me investigate on gremlin
10 replies