Simon Slavin wrote:
> It is not expected that you’ll try to run ANALYZE while a database is in use. 
>  It’s intended for offline-maintenance.

“Offline maintenance” is for servers 😝 I suspect it’s not relevant to the 
majority* of use cases for SQLite, like user-facing applications and embedded 
systems. Personally, I’ve never used SQLite in circumstances where I could 
predict when the database would be idle, since it could be triggered by either 
user or network activity.

> So why not work around the whole process ?  On your development system, 
> create a database with plausible data in.  Run ANALYZE.  Then copy all the 
> tables named "sqlite_stat*" into a new database.

That’s an interesting idea. I’ve been assuming that ANALYZE was dependent on 
the exact contents of the database, but if its results can be canned and 
applied to new databases, that’s a good optimization.

I’m just a bit wary because this isn’t documented anywhere, and generally one 
is warned against writing to `sqlite_*` tables. I’d rather have some official 
blessing of this technique before I consider using it.


* I have no idea what the breakdown of SQLite use cases is. (Does anyone?) But 
I know it’s ubiquitous in desktop apps (at least on MacOS), mobile apps, etc. 
which is where I’ve used it. And servers are probably using MySQL, Postgres, 
Couchbase, MongoDB, etc.
sqlite-users mailing list

Reply via email to