Hi Michele, the 3.0.2 release containing this fix is available for download.
Thanks for reporting. Cheers, Willi On Monday, July 4, 2016 at 5:28:26 PM UTC+2, Jan wrote: > > 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.
