[kronolith] performance on large systems

[Chuck Hagenbuch]

Quoting John Madden <jmadden at ivytech.edu>:

>> This is the open bug:
>> http://bugs.horde.org/ticket/7363
>>
>> If you have optimized SQL queries for PostgreSQL, it would be great  
>> to  get this sorted once and for all.
>
> Patch attached.  Let  me know if you feel it worthy for inclusion on  
> the bug report and I'll clean it up to remove stuff rather than  
> commenting it out, etc.  Initial testing shows massive improvements  
> (kronolith page loading the week view in ~1-2 seconds vs 5-7  
> seconds) with sharing turned on.  It's a hefty change to the logic  
> so it certainly needs someone with a better Horde background to look  
> it over.  It skips over the intelligence of Horde's DB agnostics but  
> should work on anything that supports joins and sub-selects.

I apologize for taking so long to look at this.

I would need to see the #s for MySQL, since I know it can struggle  
with subselects, but I think there's some promise here. To be  
committed, it would need to change to:

- restore checking of creator and default permissions somehow

- use $this->_table . '_users' instead of hardcoding kronolith_shares_users

- query the list of groups from the Horde_Groups object and generate  
an IN() clause from that, instead of subselecting from  
horde_groups_members (since the groups backend might not be SQL).

I'll upload your patch to the ticket for reference, regardless.

What do you think of the alternate approach of removing the bitmap  
fields and storing the permission levels (show, read, write, delete)  
separately instead?

Thanks,
-chuck