Once we've the RIDBag this issue is "only" to put this in BP right? Or we need some other structure to have vertex-centric indexes?
we do not need other structures only integration code for BP.
I'm going through the issues set for 2.0. Can you please explain this a bit. I'm hoping it addresses a issue we have :).
Thanks to the RIDBag we already have vertix-centric index structure, but we should support it in Blueprints interface in GraphQuery impl.
@enisher What's the ETA for this?
I've a very simple idea to address this feature with low effort. Please let me know what do you think. We could support VCI (Vertex Centric Indexes) by creating 2 composite NOT-UNIQUE indexes per class where we index:
In this way if I want to cross all my favorites friends, I could:
select from outE('Friend')[favorite = true].inV() from #13:33
Or, by using indexes:
select expand( rid ) from index:Profile_out_friend_favorite where key = [ #13:33, 'Friend', true ]
We could do the same by indexing target vertex's properties. AFAIK this is something Titan doesn't support. Example. If I want to cross all my friends that lives in Rome I could:
select from out('Friend')[city = 'Rome'] from #13:33
If we could support the dot notation "in-city" to create index, like:
CREATE INDEX index:Profile_out_friend_city ON Profile (@class, in.city) not unique
At this point we could use such index:
select expand( rid ) from index:Profile_out_friend_city where key = [ #13:33, 'Friend', 'Rome' ]
All this could be managed automatically by using conventions with index names. WDYT?
@lvca not so efficient as vertex centric indexes, but I like it.
However I'm not sure that it is easy in a common use case, for example for more complex queries like:
select from in("...").out("...").out('Friend')[city = 'Rome'].out("...") from #13:33
Or for cases when this construction is used in where predicate or let clause.
The other issue is that by current design out function doesn't know about following [filter clause], so we have to create a layer that will be able to optimize expression execution.
So my point is: we can easily implement it for specific case, but implement it in general would not be a low effort task with current SQL Engine design.
@enisher I agree with you. We should probably "compile" the expression or just create a new method as: OSQLFilterItemField.compile() that optimizes the own chain of fields in better way.
Usage of indexes allows us to create multiple indexing against the same collection of links. With classic VCI this is not possible.
Guys, seems we miss really significant part of design: tracking of related document changes.
That is really tricky part and vertex centric indexes is not possible without it.
@laa, @lvca let's add some extra time to create design for it.
@enisher what do you mean with tracking? We've the other issue to avoid incrementing the version of vertex in case we add an edge to boost performance on insertion and reducing conflicts.
@lvca I mean keeping vertex centric index up to date when related document fields changed.
It is not an easy issue because there are could be thousands of vertexes related to changed one, so how to find indexes that should be updated.
I think we need to allocate a time for this design issue.
@luigidellaquila will follow up with a new issue about this.
We don't need this anymore, but rather the MATCH executor will use indexes on edges if any.