[Kolab-devel] Z-push optimization

Martin Konold martin.konold at erfrakon.de
Sat Oct 2 17:48:01 CEST 2010

Am Freitag 01 Oktober 2010, 21:44:18 schrieb Jeroen van Meeuwen (Kolab 


> I understand this to result in great performance penalties, and hence I was
> thinking the following scenario might make sense to pursue for the future;
> If Cyrus were enabled to keep it's mailboxes.db, annotations.db, seen.db,
> and possibly even it's .index, .cache and .header in a true SQL database
> backend, Kolab_Z-Push would be able to use Cyrus' SQL backend as if it
> were cache.
> I've got several threads going on this approach already, so please let me
> know what you think of using Cyrus' "live" as your "cache".

Sorry, but using a SQL db as backend for cyrus dbs is simply broken as hell. 
Please don't do that.

It is plain wrong trying to gain performance for some use case by crippling 
the performance of the main use case.

On the other hand if you know which kind of information Kolab_Z-Push needs you 
may obtain it much simpler and faster without the extra penality directly from 
the cyrus dbs.

E.g. the access to Berkeley DB can be integrated savely into Kolab_Z-Push 
including proper locking if required.

Going this route means get even faster data access for Kolab_Z-Push while not 
crippling the common case.

-- martin
P.S.: There are very valid reasons why cyrus, postfix etc. use non-sql dbs!

More information about the devel mailing list