Hi Jamie, yes, the right thing to make it faster is this:
select expand(inV()) FROM SomeEdge WHERE out IN #27:819 Currently there are no work arounds for that at parser level. The problem is not tracked as a single issue because it's a wide topic, and it's being addressed as a full development process, but if you want you can create a specific issue for this Regards Luigi 2015-03-02 18:11 GMT+01:00 Jamie Blair <[email protected]>: > Luigi, > > Have you any idea how I would make this fast, or is there a work around > for the present query optimizer? Also is there a ticket I can track in > github for this? > > Thanks, > Jamie > > On Monday, March 2, 2015 at 4:55:51 PM UTC, Luigi Dell'Aquila wrote: >> >> Hi Jamie, >> >> this is a known issue, we are working hard on the new query parser and >> executor and one of the main goals of all this is query optimization. >> >> Thanks >> >> Luigi >> >> >> 2015-03-02 17:11 GMT+01:00 Jamie Blair <[email protected]>: >> >>> The following query returns a set of `@rid` and completes in about ` >>> 0.012sec` >>> >>> SELECT in FROM SomeEdge WHERE out IN #27:819 >>> >>> Now if I were to select from another Vertex using those `@rid`s in >>> there literal form, this would take a very long time and I get a timeout >>> (above 4seconds). I'm presuming its scanning over all the entries >>> >>> SELECT FROM SomeVertex WHERE @rid in [#23:83354, #23:366, #23:99933, >>> #23:80708, #23:70291] >>> >>> Interestingly enough if I were to use a single `@rid` rather than a set >>> it would be fast. So I'm assuming the query optimizer has the scope to go a >>> little further and also optimize multiple results >>> >>> SELECT FROM SomeVertex WHERE @rid in [#23:83354] >>> >>> But not to worry because I can make this faster by adding an index to ` >>> SomeVertex.@rid` so now this is fast again >>> >>> CREATE INDEX foo on SomeVertex (@rid) unique >>> SELECT FROM SomeVertex WHERE @rid in [#23:83354,#23:366,#23:99933,# >>> 23:80708,#23:70291] >>> >>> But if I compose the 2 queries, I'd expect this to be fast, but it's >>> still slow and causes timeout (above 4 seconds) >>> >>> SELECT FROM SomeVertex WHERE @rid in (SELECT in FROM SomeEdge WHERE out >>> IN #27:819) >>> >>> I'm assuming I could write this in another way, but I'm more interested >>> in why this is slow. Is this a bug or if not are there any details on >>> how/why this is slow? >>> >>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OrientDB" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
