Hi Antoni,
thanks for your feedback.
I now started a test run of our system with PARALLEL=1 and UPDINDEX=false. The system has been running without any exceptions for 17 hours. Starting with an empty data there have been almost 200K queries and commands. This is a record.
that's good to hear. My assumption is that PARALLEL!=1 and UPDINDEX=false would point to a concurrency issue, while PARALLEL=1 and UPDINDEX=true would point to a bug in the updatable data structures.
Now, what exactly are the consequences of UPDINDEX being false. Can I do queries?
Absolutely; all queries are still possible.
What kind of queries will be slower?
All those queries that depend on the value indexes (e.g., text and attribrute value indexes). See [1] for some examples.
Will the database rebuild the index automatically?
Nope; this will exactly happen if UPDINDEX is set to true. In many cases, however, it will be much faster to perform updates with UPDINDEX=false and rebuild indexes manually afterwards, using OPTIMIZE or db:optimize().
What is the command to trigger an index rebuild manually.
OPTIMIZE will recreate your outdated index structures. You may as well use CREATE INDEX to explicitly create/rebuild a specified index.
Is the index rebuild kind of a "stop-the-world" operation, so that BaseX will become unresponsive or will it be done in parallel. What are the benefits of the indices, can I live without them?
As you guessed, indexing is flagged as a write operations and will thus queue other operations. In many use cases, this works fine, because indexing is a rather fast operation in BaseX
But, quite naturally, the notion of what “fast” is depends very much on your context, and the choice for implicit or manual indexing depends on your envisaged read/write patterns.
Hope this helps, Christian
PS: I would be interested to hear if you have already thought about benchmarking 200K update operations with UPDINDEX=false, AUTOFLUSH=false and a final OPTIMIZE call.