I look forward to the longer term solution :) But in the meantime these pragmas, although not pretty, would allow solutions to specific multitasking performance issues to be explored where currently they can be difficult/impossible. I think there is a certain elegance in advisory nature of pragmas.
If manual locking is enabled, an error will be raised if a database is
accessed that has not been specified in a lock pragma.
Is it required to specify all databases accessed within the manualock scope or could it work just specifying specific databases as readonly? And the execution would error if these were violated.
/Andy
/Andy
On Wed, 13 Feb 2019 at 16:56, Christian Grün christian.gruen@gmail.com wrote:
Would this work where the database names are only known at run time?
Right now, our locking is based on static code analysis; runtime information won’t be included. In the longer term, we would like to extend our compiler to perform multiple steps:
- Static parsing
- Static optimizations (pre-evaluate 1+2 to 3, etc.)
- Dynamic optimizations (reoptimize the query with query parameters
and other context information) 4. Physical optimizations (open databases, utilize available index structures)
Queries that have been parsed and statically compiled (Step 1+2) could be stored as compiled queries, or kept in main-memory and duplicated before dynamic optimizations take place. This could further reduce access times in RESTXQ applications – and it would allow us to improve locking, as we could do the lock check after Step 3.