9 Nov
2011
9 Nov
'11
2:33 p.m.
Hi Pascal,
to your problem: Not sure if it would help (as I do not know your use case), but maybe you could start lots of queries only deleting few elements each time:
delete node (/codeBook/dataDscr/var/catstat)[position() <= 10]
If you do not need a consistent database during your delete-"transaction" (as it is none), your read-queries will be able to run in-between.
Deleting only 10 `//city`-elements in factbook took me 20ms, deleting all of them 4000ms. As there was a total of 3147 elements this increased time needed by a factor of about 1.5.
Kind regards from Lake Constance, Jens
--
Jens Erat
[phone]: tel:+49-151-56961126
[mail]: mailto:email@jenserat.de
[jabber]: xmpp:jabber@jenserat.de
[web]: http://www.jenserat.de
PGP: 350E D9B6 9ADC 2DED F5F2 8549 CBC2 613C D745 722B
Am 09.11.2011 um 14:14 schrieb Christian Grün:
> Hi Pascal,
>
> I can give you some promising prospects: yesterday, we did some
> brainstorming how to best extend the BaseX architecture to concurrent
> readers and writers (possibly by switching to MVCC), and concurrent
> write operations on multiple datbases. Work is in progress, but I'm
> positive that we'll soon be able to offer a solution that gives you
> (and everyone) more freedom for many updating use cases. In the short
> run, one feasible approach is to perform updates in one BaseX and
> database instance, and then replace the obsolete database instance
> with the updated one.
>
> We'll keep you updated,
> Christian
> ___________________________
>
> On Fri, Nov 4, 2011 at 3:16 PM, Pascal Heus pascal.heus@gmail.com wrote:
>> Lukas:
>> Thanks for the feedback. This is pretty nasty though as it makes bulk
>> updates pretty much unpractical in a multi-user environment.
>>
>> My current query was something like:
>> delete node /codeBook/dataDscr/var/catstat
>> which basically deletes all the catstat element in teh database at once
>>
>> Would this be one transaction or many transactions?
>> for $var in /codeBook/dataDscr/var
>> delete node $var/catstat
>>
>> It may stilll push my CPU to 100% though. Would there be a way to set a
>> priority for queries? For example, I may want my regular search/retrieval
>> queries to run at higher priority than the above update so users still get
>> served in a reasonable amount of time?
>>
>> best
>> *P