On Thu, 02 Aug 2012 16:51:37 -0700 NoOp <[email protected]> wrote:
> On 07/25/2012 08:35 PM, Ant wrote: > > On 7/25/2012 8:25 PM PT, »Q« typed: > > > >> The terms 'compressed' and 'optimized' are questionable here. The > >> database is rebuilt; the data is compressed within it, but the > >> file size doesn't change, so you don't gain any disk space. Also, > >> rebuilding slows some db operations, so doing it too often will > >> hurt performance somewhat. > >> > >> You could change the value of places.last_vacuum every day to > >> constantly fool SeaMonkey into thinking the database hasn't been > >> rebuilt in over a month, which should trigger frequent > >> rebuilding. That would be a bad idea, but if you want to do it > >> anyway, it's measured in milliseconds. > > > > Thanks. Bummer that it doesn't compress/shrink. :( > > Why not just use the standard sqlitemanager addin? > https://addons.mozilla.org/en-US/seamonkey/addon/sqlite-manager/ > https://code.google.com/p/sqlite-manager/ > Tools|SQLite Manager|Database|Compact Database > > Or a very nice standalone: > http://sqlitebrowser.sourceforge.net/ > http://sourceforge.net/projects/sqlitebrowser/ > File|Compact Database > > > 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. _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
