Variations of "and" and "or" not transformed to index lookups by JanusGraphStrategy

[twilmes]

In-fixed "and" and "or" predicates do not leverage indexes as aggressively as they should.

For example, with an index on name, the following queries will still result in a full scan:

g.V().has("name","marko").or().has("name","vadas")
g.V().or(has("name", "marko"),has("name", "vadas"))

Full repro steps:

gremlin> graph = JanusGraphFactory.open('conf/janusgraph-cassandra.properties')
==>standardjanusgraph[cassandrathrift:[127.0.0.1]]
gremlin> mgmt = graph.openManagement()
==>org.janusgraph.graphdb.database.management.ManagementSystem@4bd51d3e
gremlin> name = mgmt.makePropertyKey("name").dataType(String.class).make()
==>name
gremlin> mgmt.buildIndex("byName", Vertex.class).addKey(name).buildCompositeIndex()
==>byName
gremlin> mgmt.commit()
==>null
gremlin> g = graph.traversal()
==>graphtraversalsource[standardjanusgraph[cassandrathrift:[127.0.0.1]], standard]
gremlin> graph.io(IoCore.gryo()).readGraph('data/tinkerpop-modern.kryo')
==>null
gremlin> g.V().has('name','marko').or().has('name','vadas')
14:36:49 WARN  org.janusgraph.graphdb.transaction.StandardJanusGraphTx  - Query requires iterating over all vertices [()]. For better performance, use indexes
==>v[4136]
==>v[4208]
gremlin> g.V().has('name',within('marko', 'vadas'))
==>v[4208]
==>v[4136]
gremlin> g.V().or(has("name", "marko"),has("name", "vadas"))
14:49:23 WARN  org.janusgraph.graphdb.transaction.StandardJanusGraphTx  - Query requires iterating over all vertices [()]. For better performance, use indexes
==>v[4136]
==>v[4208]

[ThijsBroersen]

I can confirm this behavior. I first noticed JanusGraph is not using indexes when starting a query with a union of queries on indexed properties. It looks like it only happens for or() and union() steps, and() works as expected. I tested with integer, date and geoshape properties on both composite and mixed indexes.
All individual queries (without or() or union()) use the indexes as expected.
So (assuming indexes are set on all properties) starting from g.V() I would expect adding .union(has('name', within('marko', 'vadas')), __.has('age', gt(18))) or .or(has('name', within('marko', 'vadas')), __.has('age', gt(18))) to leverage available indexes.

[ThijsBroersen]

I don't know the underlying implementation but g.V().or(has('name', within('marko', 'vadas')), __.has('age', gt(18))) would probably be faster if optimized to g.V().union(has('name', within('marko', 'vadas')), __.has('age', gt(18))).dedup() when using indexes for both properties. Right?

[severinstampler]

Also a Not-Step containing a Has-Step doesn't make use of index lookup.
E.g. This is NOT using the index:
g.V().not(__.has('deleted', true))

whereas this IS using the index:
g.V().has('deleted', neq(true))

As a side effect, the following query with an "order by" clause is broken:
g.V().not(__.has('deleted', true)).order().by('lastChange')
where 'deleted' and 'lastChange' are both indexed fields in the same mixed index, in my particular case.