Confirmed users
595
edits
Performance/Avoid SQLite In Your Next Firefox Feature: Difference between revisions
Performance/Avoid SQLite In Your Next Firefox Feature (view source)
Revision as of 07:41, 8 April 2014
, 8 April 2014→Storage Footprint
| 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}} | * 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. | ||
* Every index contains a complete copy of the indexed data. Creating indexes on lengthy text fields 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 | ||