Confirmed users
595
edits
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 | * 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 |