[
https://issues.apache.org/jira/browse/TINKERPOP3-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14695442#comment-14695442
]
Matt Frantz commented on TINKERPOP3-702:
----------------------------------------
It would seem that a vendor-specific strategy could choose to perform any
transformation that yields the same answer.
Applying the batching logic to a loop works in some cases as long as there is
an outer loop to condense the results. If you are only performing bulking,
then the outer loop is unnecessary, as bulking is a transformation of the
representation and not the semantics.
If you are introducing "bulk opportunity barriers", then that too should not
affect the outcome. Such barriers could have the behavior you describe, i.e.
try to bulk things for a while until my iteration count exceeds a threshold.
Or it could be based on a cache size.
I don't understand the application to {{CoalesceStep}}, since the branches are
not independent, although without side-effects, you could speculatively execute
all of the branches and then choose the result of the first one that succeeds.
> Buffer input to inner traversals
> --------------------------------
>
> Key: TINKERPOP3-702
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-702
> Project: TinkerPop 3
> Issue Type: Improvement
> Components: process
> Reporter: Ran Magen
> Assignee: Marko A. Rodriguez
> Fix For: 3.0.0-incubating
>
>
> In elastic-gremlin we implement an optimized VertexStep. Part of its job is
> to batch/buffer/bulk different traversers and query them together in-order to
> minizmize the number of queries.
> You can see the implementation here:
> https://github.com/rmagen/elastic-gremlin/blob/master/src/main/java/org/elasticgremlin/process/optimize/ElasticVertexStep.java#L36
> This works great in regular traversals, the "starts" iterator returns as many
> traversers as the previous step gave out.
> But when the step is in an innerTraversal (e.g.
> g.V().repeat(__.out()).times(8)), the "starts" iterator only returns one
> traverser, and will return the next traverser only in the next call to
> processNextStart. Thus, there is no way to run a bulk query.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
