On Thu, Mar 22, 2012 at 05:28:50PM +0100, Emmanuel Lécharny wrote: > Le 3/22/12 5:11 PM, [email protected] a écrit : > >On Thu, Mar 22, 2012 at 04:40:17PM +0100, Emmanuel Lécharny wrote
> >>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. Yes... but "avoiding a full scan" is just a (coarse) optimization of the schema change. > Not sure it's a sane politic though : removing an AT from a > production server sounds a bad idea... Agreed. And again, even if it's for a valid reason, it will occur once in a blue moon. Who cares how long it takes? If you're really concerned about this scenario, sounds like a refcount on the schema elements would be more straightforward. > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com >
