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.
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. Gerv
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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.