Confirmed users
595
edits
Line 41: | Line 41: | ||
== Thoughts to be parsed == | == Thoughts to be parsed == | ||
* is expiration algorythm too complex? This actually creates problem due to slower queries, we have an hard and a soft limit, plus a limit on number of pages, that is hardly hit with default settings. Could we go back to a "Retain a maximum of XXX pages for at last YYY days" preference? Would that have any drawback? Actually often users don't notice the _at least_ indication in preferences panel, and they think that setting 0 days will get rid of they history. The lazy limit was mostly added to evaluate how much history we could retain with Places, trying to be smarter toward users, but actually is just slowing us down, and confusing users. | |||
* Should we hook into PlacesDBFlush? actually expiration code hooks into it to run just before a flush, but this makes the code more complex and less readable/self-contained... If we are going to increase number of async expiration tasks and we plan to remove temp tables, could make sense to strip out this code path from the flusher. | * Should we hook into PlacesDBFlush? actually expiration code hooks into it to run just before a flush, but this makes the code more complex and less readable/self-contained... If we are going to increase number of async expiration tasks and we plan to remove temp tables, could make sense to strip out this code path from the flusher. |