From: Robert K. <ro...@ko...> - 2006-10-27 18:15:51
|
Hi, I think I know the answer to this, but want to make sure. Concerning XUpdate in eXist, which is a faster or easier to handle XPath expression when appending/inserting nodes: 1. /root/node[@id='a']/node[@id='b'] or 2. /root/node[3]/node[2] #1 is easier for me to build, but I assume #2 is better for eXist. Perhaps it does not matter? thanks, -Rob |
From: Pierrick B. <pie...@fr...> - 2006-10-27 19:52:21
|
Hi, Robert Koberg a =E9crit : > Concerning XUpdate in eXist, Errr.... no update down there ?! Just a selection of nodes... > which is a faster or easier to handle XPath=20 > expression when appending/inserting nodes: >=20 > 1. /root/node[@id=3D'a']/node[@id=3D'b'] > or > 2. /root/node[3]/node[2] >=20 > #1 is easier for me to build, but I assume #2 is better for eXist. Both will work :-) Or are supposed to at least... The numeric predicate should be faster though, unless you have an index=20 on @id. This may change in the future though... However, as always, selective expressions are generally faster than=20 non-selective ones ;-) and... compiling an expression adds an overhead=20 which sometimes takes more time than evaluating it. Cheers, p.b. |
From: Robert K. <ro...@ko...> - 2006-10-27 20:15:37
|
Hi and thanks, (a little more below) Pierrick Brihaye wrote: > Hi, >=20 > Robert Koberg a =E9crit : >=20 >> Concerning XUpdate in eXist, >=20 > Errr.... no update down there ?! Just a selection of nodes... :) just trying to pair it down to bare essentials. The xpaths would be=20 used in an xupdate. >=20 >> which is a faster or easier to handle XPath expression when=20 >> appending/inserting nodes: >> >> 1. /root/node[@id=3D'a']/node[@id=3D'b'] >> or >> 2. /root/node[3]/node[2] >> >> #1 is easier for me to build, but I assume #2 is better for eXist. >=20 > Both will work :-) Or are supposed to at least... >=20 > The numeric predicate should be faster though, unless you have an index= =20 > on @id. This may change in the future though... I figured as much. Just hoping I could be lazy. But, what do you mean it "may change in the future"? That the #1=20 expression could be faster - or - that having an index on @id might be=20 slower ? >=20 > However, as always, selective expressions are generally faster than=20 > non-selective ones ;-) and... compiling an expression adds an overhead=20 > which sometimes takes more time than evaluating it. OK. My XUpdates will be much more rare than my XQuerys - so I will turn=20 off compilation for those (no I need to go find out how to do that :)) thanks again, -Rob >=20 > Cheers, >=20 > p.b. >=20 >=20 |
From: Pierrick B. <pie...@fr...> - 2006-10-27 20:25:28
|
Hi again, Robert Koberg a =E9crit : > :) just trying to pair it down to bare essentials. The xpaths would be=20 > used in an xupdate. Do what you want with them :-) > But, what do you mean it "may change in the future"? That the #1=20 > expression could be faster - or - that having an index on @id might be=20 > slower ? ... that we may have optimizers that could be smarter. >> However, as always, selective expressions are generally faster than=20 >> non-selective ones ;-) and... compiling an expression adds an overhead= =20 >> which sometimes takes more time than evaluating it. >=20 > OK. My XUpdates will be much more rare than my XQuerys - so I will turn= =20 > off compilation for those (no I need to go find out how to do that :)) I'm afraid every XQuery had to be compiled before being evaluated... The=20 user can't have any influence on this overhead... unless he provides=20 some better code ;-) I don't understand how you could have thought you=20 were able to turn compilation off... Cheers, p.b. |