Le 3/22/12 5:11 PM, h...@symas.com a écrit :
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.)
Makes sense. The Admin must be smart, and think before creating the
indexes...
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.
Here, it's not about optimization, really.
The idea is much more about bieng able to see if an AT removal from the
schema is likely to impact the data, without doing a full scan.
Not sure it's a sane politic though : removing an AT from a production
server sounds a bad idea...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
