Labrīt Klāvs,
well, I would the word "broken" is a strong word for something, which still works correctly and returns the correct result. It might not be perform optimal, but broken is something different. Also, given that the feature is still not even one day old, you might have to be a bit more patient with us in applying optimization techniques.
The problem here has several dimensions: - XQuery returns results in order. So in order to not break BaseX we would have to cache the results of the fetch and return it in the correct order - This caching might be much more complex, if it is a more complicated expression - It might not always be desirable to turn on parallelisation. In this case you call an external HTTP server 10 times, in this case there might be a speedup. But using fetch:text() could also point to a local URI and to parallelize I/O is not always beneficial.
So given the many different use cases here I don't think an implicit parallelization will work here to the satisfaction of everyone. Also, I invite you to read this closely related question about Haskell on SO and the linked research: https://stackoverflow.com/questions/15005670/why-is-there-no-implicit-parall...
Cheers Dirk
On 03/02/2016 01:41 AM, Klāvs Priedītis wrote:
Hello, BaseX team and community!
Disclosure: I am not yet an expert on these issues and I have not fully studied the specs of XQuery.
Now that Async Module is incorporated, I am wondering about some basic properties of xquery.
Example:
for $i in 1 to 10 return fetch:text("http://example.com/magic-story/for-number/" || $i)It feels to me that the xquery processor is broken if it cannot figure out on its own that the fetch can be done in parallel. Why does this not work out of the box? Can it work out of the box? Wouldn't it be able to do this in parallel if a flag `can-be-optimized-for-parallel-execution` was defined for the `fetch:text`?
-- Veiksmi vēlot, Klāvs Priedītis