Confirm
595
edits
Changes
m
→Storage Footprint
* 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 * 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 (like URIs) will cause very large indexes to be stored on disk
* Using the default microsecond precision for timestamps causes unnecessary bloat
