Android sucks badly.  Dont knpw who it is designed for but it sure aint me ...

Anyway, "offline maintenance" is for IT Shops to annoy their customers.  I 
think everywhere I worked for the past 40 years has been a 25 by 8 by 366 

So scheduling something for "idle hours" meant knowing that evrryone would be 
at a toga party at the same time for 3 hours next weekend and could I please 
have exclusive use for that time?

And of course it only works till the first time you exceed the window cuz aftet 
that you will never get another.

“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
sqlite-users mailing list

Reply via email to