0

https://docs.aws.amazon.com/neptune/latest/userguide/gremlin-traversal-tuning.html

This documentation mentions an important optimization affecting Neptune engine version 1.0.5.0 recommending a barrier() step during a specific traversal sequence:

g.V().hasLabel('airport').
  order().
    by(out().count(),desc).
  limit(10).
  out()

Does this strictly apply only to the order().by().limit() sequence, or would it also affect order().by().range()?

Would placing barrier() as the very last step of the traversal suffice, or does it need to come directly after limit()?

If the traversal contains multiple order().by().limit() sequences, would a single barrier() suffice, or does each instance need it's own barrier()? Note that I'm using these within project(...).by(__.order().by().limit()).by(__.order().by().limit()).

Fook
  • 5,320
  • 7
  • 35
  • 57
  • Hello. This change affects any order step. Placing a single barrier anywhere in the query, such as at the very end as you suggest, should be sufficient. Are you able to post a concrete example of the way you use `project` with `order`? That will help me verify the answer applies there as well. – Kelvin Lawrence Aug 05 '21 at 21:44
  • @KelvinLawrence Here is an example `g.V() .hasLabel("user") .order() .by("postStreakRecord", order.desc) .by( __.out("post") .order() .by("createdDate", order.desc) .limit(1) .values("createdDate"), order.desc ) .by("postCount", order.desc) .by("createdDate", order.asc);` – Fook Aug 06 '21 at 13:55
  • @KelvinLawrence Here is an example that uses nested `project` and `order` from my code. `g.V().hasLabel("alert").order().by("createdDate").limit(10).project("id", "users").by(__.id()).by( __.out("alert").hasLabel("user").order().by("createdDate").limit(10).project("id").by(__.id()) )`. Would a single `barrier()` at the end be enough? – Fook Aug 06 '21 at 15:56

0 Answers0