Performance/Avoid SQLite In Your Next Firefox Feature: Difference between revisions

Jump to navigation Jump to search
m
Line 11: Line 11:


* Features that regularly add data to the DB (e.g. visited URIs), but have no expiration policy for the data, can easily cause the DB to balloon into tens or hundreds of MBs. This is particularly undesirable on mobile devices
* Features that regularly add data to the DB (e.g. visited URIs), but have no expiration policy for the data, can easily cause the DB to balloon into tens or hundreds of MBs. This is particularly undesirable on mobile devices
* WAL journals have been known to grow very large, e.g. {{bug|609122}}, {{bug|608422}}, their size must be limited at a performance cost. More in general large transactions always cause large journals, so transactions should be kept as small as possible.
* WAL journals have been known to grow very large, e.g. {{bug|609122}}, {{bug|608422}}, their size must be limited at a performance cost
* Large transactions cause large journals, so transactions should be kept as small as possible
* Every index contains a complete copy of the indexed data. Creating indexes on lengthy text fields (like URIs) will cause very large indexes to be stored on disk  
* Every index contains a complete copy of the indexed data. Creating indexes on lengthy text fields (like URIs) will cause very large indexes to be stored on disk  
* Using the default microsecond precision for timestamps causes unnecessary bloat
* Using the default microsecond precision for timestamps causes unnecessary bloat
Confirmed users
595

edits

Navigation menu