зеркало из https://github.com/mozilla/gecko-dev.git
e9ffac0820
Until now we updated origins frecency using direct SQL triggers. While that guaranteed good performance, it also had some downsides: * replacing the algorithms is complicate, the current system only works with a straight sum of page frecencies. We are planning to experiment with different algorithms in the future. * it requires using multiple temp tables and DELETE triggers, that is error prone for consumers, that may forget to DELETE from the temp tables, and thus break data coherency. * there's not much atomicity, since the origins update must be triggered apart and a crash would lose some of the changes This patch is changing the behavior to be closer to the recalc_frecency one that is already used for pages. When a page is added, visited, or removed, recalc_frecency of its origin is set to 1. Later frecency of invalidated origins will be recalculated in chunks. While this is surely less efficient than the existing system, it solves the problems presented above. A threshold is recalculated at each chunk, and stored in the moz_meta table. This patch continues using the old STATS in the moz_meta table, to allow for easier downgrades. Once a new threshold will be introduced we'll be able to stop updating those. The after delete temp table is maintained because there's no more efficient way to remove orphan origins promptly. Thus, after a removal from moz_places, consumers MUST still DELETE from the temp table to cleanup orphan origins. This also introduces a delayed removal of orphan origins when their frecency becomes 0. Differential Revision: https://phabricator.services.mozilla.com/D186070 |
||
|---|---|---|
| .. | ||
| docs | ||
| golden_gate | ||
| modules | ||
| modules-testing | ||
| tests | ||
| tps/extensions/tps | ||
| SyncComponents.manifest | ||
| Weave.sys.mjs | ||
| components.conf | ||
| moz.build | ||