directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: PresenceIndex : why is it updated only for indexed AT ?
Date Thu, 22 Mar 2012 13:28:30 GMT
Hi Emmanuel,

On Wed, Mar 21, 2012 at 5:21 PM, Emmanuel L├ęcharny <elecharny@gmail.com>wrote:

> Hi guys,
>
> 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.

-- 
Best Regards,
-- Alex

Mime
View raw message