Hi,
I have two XQueries that do exactly the same thing, i.e. create a list
of waters in the Facts database and display where these waters flow
into, if any.
But Query 1 executes 10 times faster than Query 2 (in the GUI).
The only difference is in the selection of the query context.
Query 1 as
A bit off-topic but this weekend I ran into a strange issue with this
mailinglist.
I tried to send a message from the same e-mail address I am using now
(p...@swennenhuis.nl) but it bounced back every time I tried.
I get the feeling that the subscription is not merely e-mail based but
also IP ad
Hi Paul,
Op 4 aug. 2014, om 09:27 heeft Paul Swennenhuis <
p...@swennenhuis.nl > het volgende geschreven:
Listings: Query1 (: list waters and where they stream to (if any):) for $source in //(sea|river|lake)let $toId := $source/to/@water let $to := (//sea|//river|//lake)[@id=$
Hi Marco,
> what is the best way to copy/move collections of resources from one db to
> another?
Here is one way to do it:
db:open('source', 'a') ! db:add('target', ., db:path(.))
Cheers,
Christian
Hi Christian,
> I’m glad to tell you that I have now implemented the projected optimizations
Thank you for providing the snapshot. I’ve downloaded it and begun running some
tests.
Unfortunately I’m immediately finding some odd behaviour. I’m using the script
I provided in my original issue rep
Hi Huub,
Thank you for your reply.
I tried your suggestions, but it does not make any difference.
I changed Query 1 to this:
(: list waters and where they stream to (if any):)
for $source in //(sea|river|lake)
let $toId := $source/to/@water
let $to := //*[@id=$toId][1]
let $name := if (empty($t
Dear Christian,
Is data serialized/deserialized in your example,
Or is it working directly on the internal data format ?
Best regards,
Fabrice Etanchaud
Questel/Orbit
-Message d'origine-
De : basex-talk-boun...@mailman.uni-konstanz.de
[mailto:basex-talk-boun...@mailman.uni-konstanz.de]
James,
thanks for testing. We have a bunch of test cases that succeeded for
the rewritten index handling, but as it seems, we definitely need some
more. I'm pretty sure it's a single bug that causes all the error
messages (because the code is in itself pretty straightforward), so I
would be glad i
> Is data serialized/deserialized in your example,
> Or is it working directly on the internal data format ?
No data will be serialized in this example, but it may happen that,
due to the semantics of the pending update, you may encounter
OutOfMemory issues when copying very large documents.
Chri
> A bit off-topic but this weekend I ran into a strange issue with this
> mailinglist.
> I tried to send a message from the same e-mail address I am using now
> (p...@swennenhuis.nl) but it bounced back every time I tried.
> I get the feeling that the subscription is not merely e-mail based but
als
Dear Paul,
Is it a big collection ? Could the difference be in opening the collection ?
Did you try to run the slow request for example in the GUI, with the collection
already opened ?
Best regards,
Fabrice
De : basex-talk-boun...@mailman.uni-konstanz.de
[mailto:basex-talk-boun...@mailman.uni-
Hi Paul,
> //(sea|river|lake)
Due to the (somewhat peculiar) semantics of XPath, this path is identical to...
/descendant-or-self::node()/
(child::sea | child::river | child::lake)
...and it creates a massive amount of intermediate results. You could
try to rewrite it to...
/descendant
Hi Fabrice,
Thanks for your contribution.
The collection is the Facts database (factbook.xml) found in the
distribution of BaseX.
It's the same collection as used in Query 2.
And yes, I did try to run the slow query in the GUI. In fact, that is
the only place where I ran it, with the Facts dat
Hi Christian,
Sorry, also doesn't improve performance.
I even tried to copy the optimized line for the selection, as found in
the Query Info pane:
(: list waters and where they stream to (if any):)
for $source in ((db:open-pre("facts",0)/descendant::*:sea union
db:open-pre("facts",0)/descen
Hi Paul,
thanks for your feedback. Are you working with 7.9? If it's not too
much of a hassle for you, I would be interested to hear if you get
better performance with the latest 8.0 snapshot?
Christian
[1] http://files.basex.org/releases/latest/
On Mon, Aug 4, 2014 at 11:57 AM, Paul Swennenh
Hi Christian,
I will try that. But first: I can confirm my suspicion. The offending
line ( let $to := //*[@id=$toId][1] )
takes about 20 msecs per hit , and since there are 249 hits, that means
249 * 20 = 4980 msecs in total, almost 5 seconds!
On a side note: I discovered that BaseX's query
Hi Christian,
Just tried the query in BaseX 8.
Sorry, no improvement in performance.
Paul
Hi Paul,
thanks for your feedback. Are you working with 7.9? If it's not too
much of a hassle for you, I would be interested to hear if you get
better performance with the latest 8.0 snapshot?
Christian
Hi Paul,
thanks for trying 8.0. I have just uploaded yet another snapshot that
optimizes descendant-or-self axes and union & list expressions; e.g.:
//(sea, river)
-> (/descendant::sea | /descendant::river )
There are various other query optimizations that will be available in
8.0. But as y
Hi Christian,
Thanks again for your reply.
I'm learning a lot by discussing these kind of problems.
I tested your variant. It does indeed perform a lot better.
My Query 2 still beats it though, so I'll stick to that one for now.
Paul
Hi Paul,
thanks for trying 8.0. I have just uploaded yet an
Hi James,
I've found a little example for the bug (see attached).
Sorry for the inconvenience; I'm working on a fix.
Christian
On Mon, Aug 4, 2014 at 11:30 AM, Christian Grün
wrote:
> James,
>
> thanks for testing. We have a bunch of test cases that succeeded for
> the rewritten index handl
The bug was hidden well [1], but it should be fixed now. Could you
check out the latest snapshot?
Christian
[1]
https://github.com/BaseXdb/basex/commit/429585ce26fca98d124d78fb88216ad7317c52fa
On Mon, Aug 4, 2014 at 2:41 PM, Christian Grün
wrote:
> Hi James,
>
> I've found a little example fo
A last one for today: I have just uploaded another snapshot which
should speed up index updates.
Looking forward to your feedback,
Christian
On Mon, Aug 4, 2014 at 4:01 PM, Christian Grün
wrote:
> The bug was hidden well [1], but it should be fixed now. Could you
> check out the latest snapsho
22 matches
Mail list logo