This change will create field access hints also for AQL function calls.
Calls to functions will not be optimised, but meaningless usages of functions will not be optimised away.
For example:
FOR p IN PATHS(users, relations, "outbound")
FILTER LENGTH(p.edges) > 0 && LENGTH(p.edges) < 0
RETURN p
The FILTER in the above query uses the LENGTH() function two times in a way that no result will be produced.
Before, function calls were excluded from expression collapsing and simplification.
Now, multiple calls to the same function with the same call argument might be optimised away if the calls will
lead to no results being produced. This will only work for functions that are called with exactly one argument
which also must be an attribute name, and when the function calls are used in relational operations.
When an "outbound" query is made with the paths() function, the optimiser will now use an index if a FILTER condition can exploit an index on .source.
Example query:
FOR p IN PATHS(users, relations, "outbound")
FILTER p.source._id == "some-id"
RETURN p
The index on p._id was not exploited before, because the optimiser did not know that variable "p" related to collection "users" and that the condition actually would filter on users._id (the variable name in the FILTER statement is "p.source._id).
Now, AQL functions can define callbacks which are called by the optimiser to try some function-specific optimisations.
The optimise callback for PATHS() tries to exploit indexes for filters that filter on the vertex collection (1st parameter to PATHS() call). Indexes can be exploited if the query is an "outbound" query and there are filters on "source", or if the query is an "inbound" query and there are filters on "destination". "anybound" queries will not be optimised
Conflicts:
VisualStudio/Arango Front End Library/Arango Front End Library.vcxproj
arangod/Actions/RestActionHandler.cpp
arangod/RestServer/ArangoServer.cpp
lib/ApplicationServer/ApplicationServer.cpp
a-brandt
Jan Steemann
Oreste Panaia
Frank Celler