directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@gmail.com>
Subject [index] Presence index usage
Date Thu, 22 Mar 2012 15:40:17 GMT
Hi guys,

I will split my mails about index in smaller mails, in order to focus on 
one element at a time.

Let's first talk about the presence index.

Yesterday, I posted a question about the need to restrain this index to 
hold only the AT which are indexed. Alex explain that it was rational as 
it will cost less to store only the indexed AT in this index.

I have now a few more things to discuss about this index :

1) Do we need to have a reverse table for presence ?

IMO, no. We never use this reverse index in the current code, and there 
is no way to use it in a way it will bring some advantage. If we delete 
an entry, we will just have to remove all the <AT, entryID> tuple from 
the forward table, something we already do, no need to remove the 
<entryId,*> tuple from the reverse table.

By removing this reverse table, we save some disk space, plus some CPU 
(as we spare the removal from the reverse table).

2) What about storing all the AT into this index ?
 From the performance POV, this is not a good idea. We have around 1000 
different AT in a schema, and each entry with, say, N different AT will 
need to update the forward table for every single of those N AT. Costly.

Now, if we consider the fact that having all the AT stored in the index 
will allow us to know what will be the impacted entries if an AT is 
removed from the schema, then it can be a good thing to have a complete 
index with all the AT.

thoughts ?

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message