On 08/02/2012 07:00 PM, »Q« wrote: > On Thu, 02 Aug 2012 16:51:37 -0700 > NoOp <gl...@sbcglobal.net.invalid> wrote: ... >> >> The database was compacted using VACUUM statement. >> Before compacting: >> Page Count = 47 >> Database Size = 192512 bytes >> After compacting: >> Page Count = 47 >> Database Size = 192512 bytes >> >> The file size will be reduced if you have deleted records that haven't >> been removed previously, otherwise it will remain the same. >> https://www.sqlite.org/lang_vacuum.html > > For vacuuming, I'd be careful about sqlite versions. Doesn't SeaMonkey > have the option to use its own sqlite or use the system's? I don't > know which way is the Debian way. In either case, the add-on would use > the same sqlite SM is using. But if SM is using its own, sqlitebrowser > may be using a different version. >
SeaMonkey uses SQLite3. $ file places.sqlite places.sqlite: SQLite 3.x database, user version 17 sqlitebrowser also supports 3.x: "Jens Miltner contributed the code to support SQLite 3.x databases for the 1.2 release." and I've not run into any issues with it so far. But doesn't mean that I won't in the future, so point taken. Digging a little further regarding vacuuming the places database every month, I found these: https://bugzilla.mozilla.org/show_bug.cgi?id=512854 [VACUUM places.sqlite database on daily idle once a month] https://wiki.mozilla.org/Firefox/Projects/Places_Vacuum BTW: places.last_vacuum is depreciated and no longer used. If you load up an fresh SeaMonkey, you won't find it in 'about:config'. I still have it in this version as it's been carried over from the older prefs.js when it was valid: places.last_vacuum;1261531940 $ date --date='@1261531940' Tue Dec 22 17:32:20 PST 2009 but it's no longer there in a new/fresh SeaMonkey/prefs.js install. storage.vacuum.last.places.sqlite has replaced places.last_vacuum: storage.vacuum.last.places.sqlite;1342907499 $ date --date='@1342907499' Sat Jul 21 14:51:39 PDT 2012 Here is an interesting breakdown of places.sqlite: http://www.forensicswiki.org/wiki/Mozilla_Firefox_3_History_File_Format This might be of interest also: <https://blog.mozilla.org/nnethercote/2011/11/16/memshrink-progress-report-week-22/> Particularly: <https://blog.mozilla.org/nnethercote/2011/11/16/memshrink-progress-report-week-22/comment-page-1/#comment-4355> This is the bug report referred to: <https://bugzilla.mozilla.org/show_bug.cgi?id=692487> [Decrease Storage connections default cache_size] So whether it's advisable to vacuum manually, I don't know. I wouldn't do it without first backing up the databse being vacuumed & I'd just let SeaMonkey do it monthly on it's own, unless of course places.sqlite is growing to large each day. However, if that is the case, then it might be better to review my browsing habits, or file a bug report. On the other hand, I've not encountered a problem with vacuuming any of my sqlite databases (including the Mozilla db's) manually, but I always keep backups & perhaps I've just been lucky so far... _______________________________________________ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
