Hi, I'm trying to obtain de QueryPlan without executing the query. I try the -x -R flags on the basexclient, but with the -R flag I only receive the optimized query, not the plan. With the GUI I can stop before the end and I have the QP, but I don't know how to do that with the client.
Thank's for help
Marc
Hi Marc,
sorry for letting you wait.
I try the -x -R flags on the basexclient, but with the -R flag I only receive the optimized query, not the plan.
I just tried it on command-line, and it seems to work as expected (see below). What version of BaseX are you working with? How does your command/line call look like, and what result would you expect?
Christian ___________________________
basexclient -Uadmin -Padmin -x -R "1+2"
Query plan: <QueryPlan> <Int value="3" type="xs:integer"/> </QueryPlan>
Query "Desktop" executed in 0.29 ms.
The problem is that the xquery is so long that's it drops in time out, and in this case I don't have the QP. But with the -x and a stop of the server before the time out there is an interrupt catched by the client and the QP is out! Perhaps with a -d I don't remember.
Marc
Le vendredi 4 juillet 2014 17:08:13, Christian Grün a écrit :
Hi Marc,
sorry for letting you wait.
I try the -x -R flags on the basexclient, but with the -R flag I only receive the optimized query, not the plan.
I just tried it on command-line, and it seems to work as expected (see below). What version of BaseX are you working with? How does your command/line call look like, and what result would you expect?
Christian ___________________________
basexclient -Uadmin -Padmin -x -R "1+2"
Query plan:
<QueryPlan> <Int value="3" type="xs:integer"/> </QueryPlan>
Query "Desktop" executed in 0.29 ms.
Hi Marc,
The problem is that the xquery is so long that's it drops in time out, and in this case I don't have the QP.
Do you have any guess what takes most time? Is it really the transfer of the query string to the server, or is it the time for parsing and/or compiling the query? Do you use the default timeout of 30 seconds?
If you want, you can pass us on the query string, we can then have a look.
Cheers, Christian
Thanks for answer, but the problem comes from the use or not of the attributes index. My collection : Propriétés de la base de données Nom: FichiersBase Taille: 16425 MB Noeuds: 149424611 Documents: 6200 Binaires: 0 And i have 6,426,118 node with an @id. 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.
And after that, as the optimizer use the statistics of database, I have to analyze the query in real case, because I do a query with test data, I obtain a QueryPlan, and when I use the real data I have an other one, specially in the case where a collection as only one file, but in some other case too I think. Thats why if the QP should be output before the calculation of the query it will be better.
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.)? 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))) ....... $elem-bu := map:get($map-id,$link-bc/@linkid), $ok := concat("FichiersBase/",$nomf) = $elem-bu/base-uri()
Marc
Le vendredi 4 juillet 2014 22:14:10, Christian Grün a écrit :
Hi Marc,
The problem is that the xquery is so long that's it drops in time out, and in this case I don't have the QP.
Do you have any guess what takes most time? Is it really the transfer of the query string to the server, or is it the time for parsing and/or compiling the query? Do you use the default timeout of 30 seconds?
If you want, you can pass us on the query string, we can then have a look.
Cheers, Christian
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
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Marc