Neptunion Posts - Answer Overflow

Neptunion

•Created by Neptunion on 9/11/2024 in #questions

JanusGraph AdjacentVertex Optimization

Hiya, I'm wondering if anyone has any advice on how to inspect the provider-side optimizations being applied to my gremlin code by janus graph. Currently when I call explain I get the following output.

Original Traversal   [GraphStep(vertex,[]), HasStep([plabel.eq(Person)])@[a], VertexStep(OUT,vert
                        ex)@[b], VertexStep(OUT,vertex), WherePredicateStep(null,eq(a)), CountGlobal
                        Step, ProjectStep([COUNT(*)],[identity])]

RemoteStrategy [D]   [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]

Final Traversal      [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]

Original Traversal   [GraphStep(vertex,[]), HasStep([plabel.eq(Person)])@[a], VertexStep(OUT,vert
                        ex)@[b], VertexStep(OUT,vertex), WherePredicateStep(null,eq(a)), CountGlobal
                        Step, ProjectStep([COUNT(*)],[identity])]

RemoteStrategy [D]   [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]

Final Traversal      [RemoteStep(DriverServerConnection-localhost/127.0.0.1:8182 [graph=g])]

Which isn't very helpful of course. Secondly, I'm trying to use explain to figure out whether it's possible to have JanusGraph apply its AdjacentVertex optimisation (can find related code around here) when the vertex is stored dynamically using as rather then being a id known ahead of time. i.e. do we get adjacency behaviour from the query

g.V().as("a").out().as("b").out().where(P.eq("a"))

g.V().as("a").out().as("b").out().where(P.eq("a"))

or is it possible to get the behaviour for something similar without using two queries. Thanks in advance.

3 replies

ATApache TinkerPop

•Created by Neptunion on 4/21/2024 in #questions

Is the first traversal pattern evaluated by Match well defined

Hi, It seems to me that if the match step is able to dynamically select the first traversal pattern (as it does all other traversal patterns), and this selection isn't the same across all traversers, the behaviour of match isn't well defined. Consider the simple graph

(a) -> (b) -> (c)

(a) -> (b) -> (c)

Suppose we have some match statement with two patterns that both capture endpoint vertices x and y, such that the patterns both match x=a, y=c and x=c, y=a.

V().match( 
as("x").identity().
as("x1").both().both().as("y1").
simplePath().from("x1").to("y1").
as("y"),
as("x").identity().
as("x2").both().both().as("y2").
simplePath().from("x2").to("y2").
as("y")
).
select("start","x","y");

V().match( 
as("x").identity().
as("x1").both().both().as("y1").
simplePath().from("x1").to("y1").
as("y"),
as("x").identity().
as("x2").both().both().as("y2").
simplePath().from("x2").to("y2").
as("y")
).
select("start","x","y");

Extremely long-winded but basically both patterns will move either two out or two in (acyclicly) and capture the endpoints. If the traverser starting at vertex a evaluates the first pattern first, and the traverser starting at vertex b evaluates the second pattern first; they will both have the same result [(x=a, y=b)], instead of the expected behaviour [(x=a, y=b), (x=b, y=a)]. I'd imagine right now the first pattern is just evaluated, but I'm not entirely sure about if this is guaranteed for OLAP, and it's also not documented as far as I can tell.

2 replies

Gaming

Programming