\HasChildren incorrect

[Martin Konold]

Am Mittwoch, 19. Juli 2006 19:47 schrieb Ken Murchison:

Hi Ken,

> I like the design of the patch, but I'm not sure that using the mailbox
> sort order is correct for ALL databases (seen state, annotations).
> Perhaps the comparator function should be selectable by a flag.  I need
> to think about this a little bit.

> but I'm not sure that using the mailbox sort order is correct for ALL 
> databases (seen state, annotations). 

I am using this patch with Kolab successfully since some limited time. Kolab 
makes heavy use of annotations etc.

I quickly verified mboxlist_db quota_db seenstate_db and subscription_db.

They all look fine and working to me.

> Perhaps the comparator function should be selectable by a flag. 

This feature sould then be analogous to the way how bdb implements a user 
definable comparator function. Though I consider it currently as being 
slighly overenginered. (*)


(*) If cyrus_skiplist is supposed to become a generic db backend imho a 
selectable or better user changeable (via a callback) comparator function is 
a must but for within Cyrus Imapd I have the impression that a single 
comparator is fine according to the kiss principle.

> > BTW: What is the future of the bdb backend?
>
> Its still the most efficient backend for random access databases like
> deliver.db and tls_sessions.db

Thanks for hinting at this issue. Do you think it is feasable to improve the 
random access performance(*) of cyrus_skiplist? Maybe using suitable 
indexing?

I have the impression that from the point of view of the Cyrus imap server it 
is important that the deliver.db performes with regards to throughput and 
resource requirements not latency. I am concluding this because I assume that 
the deliver.db is mainly used for non interactive tasks.

Is this correct?


(*) IMHO performance in this context means several issues:

- latency time (how long does it take to finish a single task)

- throughput (how many potentially concurrent operations can be handled
in a fixed time frame)

- scalablity with the number of entries

- scalability with the number of concurrent accesses/sessions

- cpu usage

- memory usage

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker