Hi Marc,
And for example, I discover that : $r := collection("FichiersBase")//*[@id='R1C862AF55D1BEBC-EFL']/base-uri() doesn't use the attribute index, but $v := collection("FichiersBase")//*[@id='R1C862AF55D1BEBC-EFL'] $r := $v/base-uri() uses it.
I'm glad to say that queries of this kind are already optimized in Version 8 [1].
And after that, as the optimizer use the statistics of database, I have to analyze the query in real case [...]
Interesting approach. Do you use different queries because query evaluation would be too slow otherwise, or are there some more reasons? In the first case, we could have a look at these types of queries in order to find out if they can be sped up by BaseX.
Thats why if the QP should be output before the calculation of the query it will be better.
As the query plan and all related information will be retrieved in a single step by the client, it's currently not possible to first send the plan, then evaluate the query and then send the final information. But I'll keep your suggestion in mind.
I have a question about the attribute index, does it will be better if I do a collection with only node with the @id attribute and the data I need in my queries, no other data (text(), unsual attribute etc.)?
It might be interesting to find out what's the major bottleneck. As the attribute index contains values of all attributes, it could be that the queries will be evaluated faster when reducing the number of attributes. Text nodes shouldn't play a role in this case. -- In our own use cases, if performance is critical, we do something similar: We create custom XML structures that only contain the information required for search operations.
For example I do a map at the beginning of the query to "load" the part of the attribute index I use in memory, so my query takes always the same time else sometimes it takes a long time to read the attribute index. let $map-id := map:new (for $id in (collection("FichiersBase")//*[@id]) return (map:entry($id/@id, $id)))
Using maps is a good choice for that. Reg. performance again: you could try to directly access the index via db:attribute [1] in order to find out if it's really the index access that takes too much time, or the subsequent path operations.
Hope this helps Christian
[1] http://files.basex.org/releases/latest/ [2] http://docs.basex.org/wiki/Database_Module#db:attribute