This has just been fixed in the 3.0 and devel branches. The fix will be contained in 3.0.2. A temporary workaround is to split the one FILTER statement in the second query into multiple smaller FILTER statements and move them near their respective FOR loops. Best regards Jan
Am Montag, 4. Juli 2016 16:44:54 UTC+2 schrieb Jan: > > I tried to reproduce the behavior locally and I think I am seeing that > same problem. > In the latter query (the one that does not use indexes), the query > optimizer executes a function that will move the FOR loops around in the > query. It will try to create all possible permutations of FOR loops that > don't change the meaning of the query. In the latter query, the optimizer > is free to move around any of the 9 FOR loops, because there are no FILTER > statements between them that could be problematic. So the optimizer will > start creating new execution plans with FOR loops moved around. This could > create 9! (faculty, i.e. 362880) different execution plans, but by default > the optimizer stops at 192 plans in order to avoid that combinatoric > explosion. And when that number of plan is reached, the optimizer will stop > applying some optimizations in order to put a cap on the overall > optimization runtime. > That's the reason why in the second query the "EnumerateCollectionNode"s > are not converted into "IndexNodes". The optimizer has stopped before this > step because there are already so many execution plans. > In the first query, the optimizer is not as free to move around the FOR > loops, because the FILTER statements restrict some of the movements. And > because of that, it will not generate as much execution plans and not stop > optimizing prematurely. > > I am currently looking into how this can be made a bit smarter. > > Am Montag, 4. Juli 2016 09:43:56 UTC+2 schrieb Jan: >> >> Can you supply the collection types (document/edge) and index definitions >> for the collections that are used in the query. That may help diagnose this >> further. >> You can get the index definitions via >> >> db.<collectionname>.getIndexes() >> >> Thank you and best regards >> Jan >> >> Am Sonntag, 3. Juli 2016 11:37:05 UTC+2 schrieb Michele Ippoliti: >>> >>> btw.. the first query is longer.. >>> but this doesn't change the question. >>> >> -- You received this message because you are subscribed to the Google Groups "ArangoDB" 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.
