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
