W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [WebSQLDatabase] Adding a vacuum() call

From: Jeremy Orlow <jorlow@chromium.org>
Date: Fri, 5 Mar 2010 10:38:57 +0000
Message-ID: <5dd9e5c51003050238o6053e752n49e25f9b600eae60@mail.gmail.com>
To: Joćo Eiras <joaoe@opera.com>
Cc: public-webapps <public-webapps@w3.org>
On Fri, Mar 5, 2010 at 2:32 AM, Joćo Eiras <joaoe@opera.com> wrote:

> On Fri, 05 Mar 2010 03:22:00 +0100, Dumitru Daniliuc <dumi@chromium.org>
> wrote:
>
>  Hi,
>>
>> We (Chromium) would like to add a vacuum() call on the Database object.
>>
>
> [...]
>
> I would argue about having something a bit more generic for naming like
> "defragment()".
>
> I don't see how the callbacks are useful though. Vacuum works
> transparently, its effects are not visible, and what should the page do in
> case of error ?
>
> Given that an operation like vacuum would be disk IO intensive, would it be
> good to give the webpage control over a feature that can have significant
> performance concerns ?
>

I'm sure a UA could always ignore it and/or vacuum whenever it wants...but
the drawback is that if you start vacuuming and then the app tries to open
the database, you might get some serious jank in the web app.


> While computers benefit from good file IO performance, that's not quite
> true in many mobile devices. So, the API would be more like an hint ? How
> can the webpage know the level of fragmentation of the data file ?
>
> Sqlite supports incremental vacuum http://www.sqlite.org/pragma.html so
> this kind of feature should be left for sqlite to handle for itself.
>

>From that page:
"""
Note, however, that auto-vacuum only truncates the freelist pages from the
file. Auto-vacuum does not defragment the database nor repack individual
database pages the way that the VACUUM <lang_vacuum.html> command does. In
fact, because it moves pages around within the file, auto-vacuum can
actually make fragmentation worse.
"""
Received on Friday, 5 March 2010 10:39:48 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:37 GMT