Hi Christian, The XPath I showed was just a simple example of using the preceding-sibling axis. Of course, I am really interested in more useful queries such as:
//tns:poi[not(tns:id = preceding-sibling::tns:poi/tns:id)]
I guess what I am asking is ... while most XPath queries I run are quick to resolve, anything using preceding::, preceding-sibling:: or following::, following-sibling:: essentially runs too slowly to be workable - at least, on my sample dataset with about 100K sibling children of the root element.
So is this any sort of known issue? Should I be looking at any sort of configuration options? Is there any way to profile the execution of the Xpath?
Cheers,
C.
-----Original Message----- From: Christian Grün [mailto:christian.gruen@gmail.com] Sent: Wednesday, October 19, 2011 8:56 PM To: Constantine Hondros Cc: basex-talk@mailman.uni-konstanz.de Subject: Re: [basex-talk] Performance of Basex 7.0 XQuery execution
Constantine,
thanks for the kudos.
/tns:pois/tns:poi[not(preceding-sibling::tns:poi)]
If I get it right, you're trying to select the first tns:poi/ element in your query. This can also be done via
/tns:pois/tns:poi[1]
After all, I still might have a deeper look at the performance of your query, as 30 minutes would of course be terribly slow.
Hope this helps, feel free to ask for more,
Christian BaseX Team ______________________________
So the immediate question is whether this performance is to be expected. If not, what are the obvious things to look at in terms of performance tuning?
Thanks in advance, Constantine
Constantine Hondros | Senior Data Engineer | TomTom Places | constantine.hondros@tomtom.com | +31 (0) 88 245 6239 office | +31 (0) 6 402 14838 mobile | places.tomtom.com
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk