Hi, I can't tell if views will handle this query very differently, but I doubt that when using a view the extra `COLLECT` step will be removed. That's not to say that there will be no performance difference when using views (I simply don't know). But when it comes to the `COLLECT`, I guess it will still stay around in the query even if a view is used.
I guess the query could be most improved by implementing the distinct operation directly on the index, which would remove the extra `COLLECT` step entirely. But that functionality is still a future to-do and not available yet. Best regards Jan Am Sonntag, 19. Mai 2019 15:29:45 UTC+2 schrieb Andreas Jung: > > Running ArangoDB 3.4.5 on a collection with 100.000 items. > Each item has singe-valued field _type and there are about 20 different > values for this field. > The field is indexed by a hash index: https://nimb.ws/yh4rRb > > This query performs a full table scan instead of using the index. > Am I missing something here? > > For doc in import > return distinct doc._type > > Query String: > For doc in import > return distinct doc._type > > Execution plan: > Id NodeType Est. Comment > 1 SingletonNode 1 * ROOT > 2 EnumerateCollectionNode 95238 - FOR doc IN import /* full > collection scan, projections: `_type` */ > 3 CalculationNode 95238 - LET #1 = doc.`_type` /* > attribute expression */ /* collections used: doc : import */ > 4 CollectNode 76190 - COLLECT #3 = #1 /* > distinct */ > 5 ReturnNode 76190 - RETURN #3 > > Indexes used: > none > > Optimization rules applied: > Id RuleName > 1 reduce-extraction-to-projection > > > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/arangodb/0c325e78-45fd-4224-8de3-38dc49ecec4f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
