On Wed, Mar 21, 2012 at 5:21 PM, Emmanuel Lécharny <email@example.com>
as I was reviewing the presenceIndex usage this morning, I found that we only add entries in this index if the AT is indexed.
This is correct and was explicitly intended for this exact behavior. More below on why ...
For instance, if the sn AT is indexed, then we will have some <sn, EntryID> elements in the presence index.
Is there any rational beind this choice ?
This decision was made a while back. The rational was if an AT is not indexed, having it's own index, then adding entries for that AT on any system index might create complications that don't necessarily benefit performance in a consistent fashion. Plus it might actually significantly harm performance and unnecessarily bloat some system indices. This is an all or nothing approach. Otherwise behavior will be more difficult to understand and manage as well.
Otherwise, that means we will do a full scan on the master table when we have a filter like (sn=*) if the sn AT is not indexed...
Yep and the user should index sn if he's going to use it in search filters. All indexing is enabled even on use of system indices if the AT is indexed otherwise we do nothing for that AT. If you want (sn=*) to perform fast just as (sn=dickens) then index the surname attribute. Also another premise is, if you will want to use (sn=*) you're likely going to use (sn=foo) too at some point in your applications. So the all or nothing approach probably pays off. In the end the all or nothing 0 or 1 approach is much simpler and easier to understand. You have an index, no deserializing needed in any filter assertion with the indexed AT. If no index then you're screwed regardless of the filter assertion operand used.
The alternative of course has not been tested so this theory may not be reality when tested. It would be nice to test but I think we should do this in an experimental branch.