Re: [Tracker] Sqlite now default in cvs (mysql backend wont compile yet!)

[Anders Aagaard <aagaande gmail com>]

Jamie McCracken wrote:
> Anders Aagaard wrote:
> > Jamie McCracken wrote:
> > > I have ben spending the last few weeks adding in the sqlite/qdbm
> > > complete with indexer and parser.
> > >
> > > This is now basically functional in cvs.
> > >
> > > Stuff that wont work is :
> > >
> > > 1) RDF query
> > > 2) only tracker-search (no location or mime yet in nautilus)
> > > 3) exact phrase search
> > >
> > > I have not updated the mysql backend yet so it wont compile at the
> > > moment so you are *forced* to try out the sqlite one :)
> > >
> > > (I figure unless theres a strong reason to have the inferior mysql
> > > version we can phase it out?)
> > >
> > > New features with new indexer are:
> > >
> > > 1) differential indexing for faster updates
> > > 2) stemming so searches for "penguin" will match against "penguins"
> > > 3) Bzip compression of full text so it has much smaller footprint in
> > > the sqlite db
> >
> > Why chose bzip?  Considering it's performance I'd rather choose gzip, or
> > if your desperate for space 7zip (there are open linux implementations,
> > p7zip or something like that).
>
> bzip has the best compression available.
>
> If I want to balance speed and compression I would go for zlib which is
> a distinct possibility - how do people feel about this?

In my experience in compression (and it's actually quite considerable),
the increase in compression ratio (especially with relatively small
amounts of data, like you here) with bzip is extremely small.  I'd
imagine on a 100mb database you'd be saving 2-3mb using bzip over zlib.

> trade more disk space for faster indexing of text based files/documents?
>
> (could always do both and make it a compile option)