archive older history to a separate database




11 years ago
6 years ago


(Reporter: dietrich, Unassigned)



Firefox Tracking Flags

(Not tracked)




11 years ago
schrep in bug 381795:

But it seems like capping the size of this table overall + size of URL's might
give us slightly better behavior.  We could look at putting a hard cap on the
main db which fires for the URL bar and then add a "search everywhere" button
or equivalent to go pickup data from further back in a separate db (that gets
loaded only on demand)... This basic problem is an archiving one that
partitioning solves well.

Comment 1

10 years ago
an alternative idea could be to flatten all we need from history in moz_places, and use historyvisits table only when we need to update cached data in moz_places.
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Component: Places → Bookmarks & History
QA Contact: places → bookmarks
considering the existence of moz_places table and a separate history table, this would be hard to do, and not sure it would actually perform any better since we should move stuff across the 2 tables in a lot of cases.
I think the current automatic expiration algo works fine for now, if we'd ever consider this, would be in a totally new database design.
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.