Re: [Tracker] support for other database backends?

[Jussi Laako <jussi laako linux intel com>]

Hi Ivan,

>  For example, libtracker-sparql is using direct access to sqlite for
> reading and the tracker-store daemon via dbus for writing. Postgres
> has a client-server architecture itself... that means a heavy
> rewritting of libtracker-sparql internals or losing performance in an
> extra IPC roundtrip.

Of course idea would be to drop dbus and a separate daemon altogether 
from the picture.

>  Do you have any specific reason for postgres? Some people tested that
> (for mobile devices) and the conclusion was that sqlite is ok: we are
> in the "comfort zone" of sqlite, so postgres wouldn't give us any
> sensibly better results.

It provides really flexible event notification straight from the SQL 
statements (see LISTEN/NOTIFY). Also dbus signals can arrive 
out-of-order compared to database transaction ordering. Postgre nicely 
optimizes also writes, caching (no need to sync/re-read from the fs 
layer to get updated data after writes), etc.

So the nice part is that postgre provides all needed parts in one 
optimized package:
 - Multi-process shared database access
 - All needed IPC
 - Change notifications triggered straight from the database transaction


        - Jussi