From kolab-devel  Sat Oct 02 15:48:01 2010
From: Martin Konold <martin.konold () erfrakon ! de>
Date: Sat, 02 Oct 2010 15:48:01 +0000
To: kolab-devel
Subject: Re: [Kolab-devel] Z-push optimization
Message-Id: <201010021748.02886.martin.konold () erfrakon ! de>
X-MARC-Message: https://marc.info/?l=kolab-devel&m=128603449312007

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

Hi,

> 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.

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

_______________________________________________
Kolab-devel mailing list
Kolab-devel@kolab.org
https://kolab.org/mailman/listinfo/kolab-devel