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/
