Overview
Sprint lead: YOURNAMEHERE
Sprinters:
- Description
- Periodically vacuum SQLite databases created by Firefox.
Goals / Use Cases
- Definitively determine if there's a performance benefit to vacuuming.
- Vacuum in an unobtrusive manner that does not interrupt the user.
- OPTIONAL: Expose a chrome-space function for triggering vacuum that can be called from the console.
Non Goals
- Add a UI component for manually triggering vacuum.
Design
[list]
[*]Perfect solution would be to ask Sqlite team to implement defragmentation in incremental vacuuming. Actually incremental vacuum is just removing freelists but not compacting the db, that could create more fragmentation and make things worst. That's why it's not used actually.
[*]Need to work on our specific solution while this is is not implemented upstream. Solving the issue globally would be better than creating a browser only component, but will be even harder because will have to take in count all possible setups of various kind of dbs (exclusive, shared, ...).
[*]Need to find a good time to do the work, the main point is that it should in no way block users' activities. Two possible solutions are on a major update or on idle. The former has the advantage that is executed in a moment where the user is "prepared" to expect some time for the new version, and would be completely transparent to him, has disadvantage that will slowdown update and is possible only for browser, we can't guess update strategy of other apps. On idle has the advantage that won't hit a specific moment in which the user is doing something, but has other disadvantages due to the fact: it could hurt other tasks (maybe user is watching a video and we will cause skipping) or stop a laptop from going standby (had similar issues with frecency).
[*]Vacuum only if really needed. First of all doing vacuum too often could be bad for inserts since they usually reuse freelists pages, and that is faster than creating a new page. Doing it every 6 months is probably enough, but we can also get a guess if it should be done or not. We can compare PRAGMA page_count with PRAGMA freelist_count, if there is a large enough number of pages in the freelist is most likely that vacuum will help. This is a large guess, but could work to avoid some useless work, just need to find a good percentage, and maybe still force a vacuum even if is not needed after 2 or 3 tries. A better guess can be only obtained by directly accessing the db file and counting used bytes page by page, this is something done by sqlite_analyzer, but is a slow process.
[/list]
Bugs
- bug 403702 - add a "compact db" button
- bug 484646 - thunderbird vacuum strategy bug