Hi, What is the problem being addressed by this change? We do not allow for multiple indexes creation at a time. The only possible way to create an index is CREATE INDEX command when only one index is created.
On Tue, Apr 17, 2018 at 10:08 PM, Manu <maxn...@hotmail.com> wrote: > Hi! > > I have taken a look at this new functionality and it is very interesting. > But I have a couple of doubts about the performance. > > For each modification of the same QueryEntitity, a new > SchemaAbstractOperation is generated, in the case of adding columns the > performance is not affected, but in the case of creating new indexes I > think > there is a problem: > > - If the modification in the QueryEntitity contains the creation of N > indexes, N SchemaIndexCreateOperation are generated for the same table, > this > causes the underline cache to be scanned N times to populate each indice > (by > SchemaIndexCacheVisitorClosure). For caches with a few data is not a > problem, but for caches with millions of records is not optimal. > > A possible solution would be to create a new type of > SchemaAbstractOperation > (for example SchemaUpgradeQueryEntityOperation with the new QueryEntity, > boolean forceRebuild, boolean forceMutateQueryEntity), to register on one > block this new QueryEntitity for: > > - Create new indices at same time (populate all indices with a single scan) > (auto, like now) > - With on demand forceMutateQueryEntity (ignore QueryEntity patch checks), > ability to eliminate indices (and fully release resources) and columns. > Over > time the QueryEntity will evolve and at some point it is possible that > certain columns and indices are not necessary any more... I think it would > be interesting to allow trim indexed data and eliminate unused columns. > > Hope it helps! > > Regards > > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >
