On Thu, Mar 22, 2012 at 04:40:17PM +0100, Emmanuel Lécharny wrote: > 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 : > > 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.
My rule of thumb is only index attrs that are actually used in search filters, and only if their frequency in the db is low. (If an attr is present in 100% of entries, then the index is totally superfluous.) > 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. It's an interesting idea, if the admin was going to index it anyway. Otherwise, IMO you're optimizing for a very infrequent case, which is self-defeating. > > thoughts ? > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
