Re: [Exist-open] FLOWR expressions evaluation

[Wolfgang M. <wol...@gm...>]

Hi Adam,

> Am I right in thinking that dependency calculations are used to find out
> what parts of a query depend on other parts of a query?

Right now, dependencies are mainly used to determine if eXist-specific
optimizations can be used or not. eXist often tries to escape the
simple top-down processing model described in the XQuery spec and uses
batch-processing of node sets instead to speed up execution. However,
this is only possible for expressions that do not directly depend on a
single context item, but can operate on the entire context set at
once. Most functions can't do it, but some can. fn:not is a good
example: in some cases (the argument has flag Dependency.CONTEXT_ITEM
set) it will just evaluate the boolean value of the argument for each
item in the context sequence. In other cases (context sequence is a
node set and arg doesn't signal a dependency on CONTEXT_ITEM), not()
is implemented as a set operation, which is many times faster. This is
difficult to understand from the code, but the basic rule is: use set
operations wherever you can!

So while dependencies would certainly play a role when you try to
parallelize operations, there will be many other things to consider.
From my point of view, you should probably take a different direction
and first add a feature to the query engine that allows you to
manually parallelize certain parts of the query by moving them into
their own thread of execution. I could imagine a dedicated "thread"
module which provides a set of base functions for thread management
and merging of results.

Wolfgang