Hi Menashè,
First of all, I wonder if your query really does what you want it to do. I noticed for example that some of the where conditions start with "$x/", while others start with "/" and some others start with no slash. Is this intentional?
Some more comments:
* I would recommend you to avoid numeric tests in the @codeListValue tests and use string tests instead (/@codeListValue = "7827", etc). * Usually, you can also get rid of the xs:dateTime() conversions, because items of type date and time can also be compared as strings. * I'm not sure what the predicates [*] are supposed to do in your query. If you remove them, you will get the same results. * In some cases, if you know that an element name is distinct, you can get rid of all the explicit child steps and directly address the node via the descendant axis.
So reordering the conditions for having smaller subset right from the begging isn't relevant.
Reordering shouldn't make a big difference anyway, because BaseX tries to find the cheapest index request by itself, based on the database statistics.
Beside that, I would be interested to hear if you get better results with BaseX 8.0 [1], because we recently spent quite some time to further improve our index rewriting rules.
Hope this helps, Christian
[1] http://files.basex.org/releases/latest
On Fri, Jan 30, 2015 at 3:55 PM, Menashè Eliezer meliezer@ogs.trieste.it wrote:
Hello, I wonder if the attached query can be optimised. I'm attaching all relevant information. Basex 7.9, Debian, powerful server. This is just an example. The queries will be built based on a compilation of a search form. Any help would be appreciated. 40 seconds are not acceptable.
-- With kind regards, Menashè