Closed Bug 487809 Opened 11 years ago Closed 8 years ago
Stop using visit
_count to invalidate frecencies
Bug 416313 added the original setting of frecency to -visit_count, and this included among other changes.. reordering some queries so that we can grab visit_count before we wipe the visits. Bug 476298 made it so that we just recalculate all invalid frecencies in one go, so there's no need to order by the negative frecencies.
Oh, I forgot to emphasize the main reason :p Because we do frecency = -MAX(visit_count, 1), some queries are more complex than necessary especially while expiring. Such as getting the visit count of pages that we *won't* expire, then expire the pages. Whereas we could just expire pages and set the remaining pages' frecency to -1.
This is a sensible improvement to do, taking since I just hit this code in another bug and remembered there was a bug filed about this.
Assignee: nobody → mak77
Summary: Determine if we still want to set frecency to -visit_count on clearing → Stop using visit_count to invalidate frecencies
First use of UPDATE WHEN CASE END, I originally thought it was only for SELECTs, I'll find more uses for it. Btw, before we were setting frecency to -visit_count for all entries that we evaluated to stick after cleanup, removing pages, then fixing frecencies for unvisited livemarks and place: queries. With the patch we just asynchronously set frecency to -1 or 0 on the remaining entries after the cleanup, this has some advantages: query is simpler, 1 query rather than 2, async IO. This bug depends on bug 674210 from a code-merge point of view.
Attachment #556676 - Flags: review?(dietrich)
Attachment #556676 - Flags: review?(dietrich) → review+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
You need to log in before you can comment on or make changes to this bug.