[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SQLite vacuum or auto_vacuum?

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Mon, 3 Dec 2012 23:20:53 +0400

On Mon, Dec 3, 2012 at 4:39 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
>
> On Mon, Dec 3, 2012 at 7:08 AM, Philip Martin <philip.martin_at_wandisco.com>
> wrote:
>>
>> Prompted by a question on users I wondered how SQLite's vacuum
>> (http://sqlite.org/lang_vacuum.html) would affect wc.db size. On a
>> Subversion trunk working copy I have been using for months the size was
>> reduced from 2.3MB to 1.3MB which isn't really a significant change.
>>
>> For a further test I checked-out a ^/subversion/branches working copy
>> for a wc.db of 93MB with 121738 rows, I made it sparse with 66046 rows
>> and it was still 93MB, then I ran vacuum and it was reduced to 51MB. I
>> have a gcc working copy with some subtrees switched to an empty
>> directory. There vacuum reduced wc.db from 47MB to 8.1MB.
>> So it appears that vacuum is interesting if the number of rows decreases
>> dramatically.
>>
>> SQLite has auto_vacuum but it comes with a warning that it may make
>> fragmentation worse (http://sqlite.org/pragma.html#pragma_auto_vacuum)
>> so it's not clear whether we should enable it. Perhaps we should add a
>> "vacuum" to cleanup? A full vacuum rewrites all the tables so it's not
>> a trivial operation but it is reasonably fast for the working copies on
>> local disk that I tried.
>
>
> I think adding "vacuum" to cleanup is a reasonable first step. "cleanup" is
> an explicit operation that a user could reasonably expect to take some
> non-trivial amount of time. We already remove unneeded pristines during
> cleanup, might as well do the same thing with wc.db space.
>
+1.

-- 
Ivan Zhakov
Received on 2012-12-03 20:21:47 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.