Parallel selects with IndexedDB

[steida]

Is it possible to somehow batch/group selects? What is the fastest way to read several selects? Thank you

[rhashimoto]

You might be wondering whether passing multiple statements to sqlite3.exec is faster than using the lower level functions. That would likely be true if it simply called the SQLite API function as that would cross the Javascript/WebAssembly language boundary fewer times, but wa-sqlite implements its own exec in Javascript so there shouldn't be any difference.

Otherwise the considerations are basically the same for optimizing any SQLite application; make sure your queries are efficient and tune to avoid system calls. So things like:

• If you're using a filesystem that uses locks to allow concurrency (like the example IndexedDB or OPFS VFS classes), limit the number of locks by putting multiple statements in a transaction (when that makes sense), or use PRAGMA locking_mode=exclusive which protects the whole session with a lock.
• Increase the cache size.
• Use EXPLAIN QUERY PLAN and/or EXPLAIN to understand why queries might be slow (and could possibly be improved, e.g. with indexing or reworking the query).
• If possible, amortize parsing by preparing statements (with optional parameter placeholders) once and executing them many times.

[rhashimoto]

Rereading your question, I think you were more interested in whether there was a way to get more throughput by submitting read-only SELECTs on multiple database connections. That won't work properly in a single Javascript context (unless you ensure only one connection is used at a time, which defeats the purpose). It could conceivably work if you access a database from separate contexts, e.g. multiple workers, but whether it would actually be faster depends on your workload and your platform. In particular, your queries would almost certainly need to be CPU-bound rather than IO-bound. Also note that you would need shared locks (e.g. replacing WebLocks with WebLocksShared) which means your application would need to handle SQLITE_BUSY (with ROLLBACK and retry) if it ever writes to the database. I think you would have to be pretty motivated to try it because it is a decent amount of work and might well end up being slower.