Investigate 'PRAGMA optimize'
Categories
(Firefox for iOS :: Data Storage, enhancement, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| fxios | 16.0 | --- |
People
(Reporter: justindarc, Assigned: justindarc)
Details
|
Assignee | |
Updated•6 years ago
|
Nervous about doing this on close, and the implications of killing the process while the DB is being optimized. I wonder what is the added risk of DB corruption from this.
|
|
Assignee | |
Comment 2•6 years ago
|
||
I don't want to do it on close either since one of the cases where we call close() is when we're being forced to shutdown by the OS. We already have a good spot for this where we check if we need to prune old history at startup. Also, the documentation says:
This pragma is usually a no-op or nearly so and is very fast.
It also looks like you can supply arguments to limit which optimization routines it performs. I think we can safely do this at startup with little-to-no performance penalty (except for maybe the first time it runs on a large DB that hasn't been optimized yet). I'll investigate this further and see what we should do.
Also, I was mistaken before when I said that we are already running VACUUM regularly. It seems that the only time it is run currently is if the user clears their history. We should also probably run this during our optimization/pruning routines at startup, but not nearly as often.
|
|
Assignee | |
Comment 3•6 years ago
|
||
Actually, I'm wrong. The proper time to do this is at close. It uses the stats gathered throughout the life of the connection to make optimizations. More often than not, it is a no-op, but even when it does do work, it completes very quickly.
|
|
Assignee | |
Comment 4•6 years ago
|
||
Landed on master:
https://github.com/mozilla-mobile/firefox-ios/commit/9a39a661e2f02e1e1b28c19871e2a2af21d34589
Description
•