On 8/3/12 2:02 PM, NoOp wrote: > On 08/02/2012 07:00 PM, »Q« wrote: >> On Thu, 02 Aug 2012 16:51:37 -0700 >> NoOp <[email protected]> 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... >
Note that bug #512854 only addressed places.sqlite and has been implemented. Bug #538493 addresses ALL SQLite databases and has not yet seen any attempt to implement it. See <https://bugzilla.mozilla.org/show_bug.cgi?id=538493>. -- David E. Ross <http://www.rossde.com/>. Anyone who thinks government owns a monopoly on inefficient, obstructive bureaucracy has obviously never worked for a large corporation. © 1997 by David E. Ross _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
