Places:FsyncApproach: Difference between revisions

(→‎Long Open Transaction Approach: Updated cons and swag)
 
(5 intermediate revisions by 2 users not shown)
Line 23: Line 23:
* modify all queries that interact w/ the partitioned table(s)
* modify all queries that interact w/ the partitioned table(s)
* periodic flush of temp to permanent table (ensuring pk sync)
* periodic flush of temp to permanent table (ensuring pk sync)
swag: 3+ weeks


=Long Open Transaction Approach=
=Long Open Transaction Approach=
Line 39: Line 41:


Pros:
Pros:
* Less overall fsycns
* Easy (almost painless)


Cons:
Cons:
* Can lose data if we crash with an open transaction
* Still involves writes to disk
* If anyone else (non-places) fsyncs, we still lose
* Can no longer make a group of operations atomic with transactions (no nested transaction support).
swag: 1-2 weeks


=Split Database Approach=
=Split Database Approach=
Line 48: Line 58:


Pros:
Pros:
* The common task of adding a history visit is cheaper


Cons:
Cons:
* Likely false assumption that history is less important than bookmarks (smart location bar changed this)
* Tight coupling between the two databases
* New history visits require a write to both (likely)
swag: 1-2+ months


=Grow File in Large Hunks Approach=
=Grow File in Large Hunks Approach=
Line 72: Line 88:
* Still waits on ([https://bugzilla.mozilla.org/show_bug.cgi?id=421482#c152 less significant disk access]) regularly, and so may need to be combined with async IO or another approach for optimal behavior.
* Still waits on ([https://bugzilla.mozilla.org/show_bug.cgi?id=421482#c152 less significant disk access]) regularly, and so may need to be combined with async IO or another approach for optimal behavior.


swag: 2 weeks


=Journaling Virtual Filesystem Approach=
=Journaling Virtual Filesystem Approach=
Line 115: Line 132:
* More complicated than Grow File in Large Hunks Approach
* More complicated than Grow File in Large Hunks Approach
* Data is written twice and so there is twice as much IO.  But this could be counter balanced by disabling sqlite's journal provided transaction completion can be detected by the vfs.
* Data is written twice and so there is twice as much IO.  But this could be counter balanced by disabling sqlite's journal provided transaction completion can be detected by the vfs.
swag: 2-3 months
590

edits