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. —Jens * 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 sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
