On Thu, Mar 22, 2012 at 05:28:50PM +0100, Emmanuel Lécharny wrote:
> Le 3/22/12 5:11 PM, firstname.lastname@example.org
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 theYes... but "avoiding a full scan" is just a (coarse) optimization of
> >>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.
the schema change.
Agreed. And again, even if it's for a valid reason, it will occur once
> Not sure it's a sane politic though : removing an AT from a
> production server sounds a bad idea...
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.