Hi guys, Hi Joaquín, I have a question concerning the automatic re-indexing of Boost.MultiIndex indexes. Is it somehow possible to modify a member of the element-type that is used as key for (another) index without triggering automatic re-indexing? (Of course, I want to be able to trigger manual re-indexing later.) Or is it at least possible to adjust the code so that this can be achieved? To understand my question, here is my use-case and why I need it. I have a boost::multi_index_container with multiple indexes (one hashed_unique and four hashed_non_unique). I am accessing a range of elements through a hashed_non_unique index 'A'. Then I am iterating through these elements and want to modify the value of a member 'M' of each element. However, that member is used when calculating the key for another hashed_non_unique index 'B'. Therefore, I must use the "modify" function of index 'A'. The problem is now that it takes forever to modify the entire range. (We are talking about 100 thousands if not millions of entries that need to be modified.) Probably because re-indexing is triggered after each call to "modify". However, in my case it should be perfectly fine to postpone the re-indexing after I modified the entire range, because I am not going to access any element through index 'B' until I finished modifying the entire range. As a workaround I removed index 'B' from the container and declared the element-member 'M' as mutable. This allows me to directly change the value of 'M'. The speedup is astonishing. It now finishes almost in no time. But this workaround is not really feasible as it requires reimplementing index 'B' by somehow tracking the information outside of the multi_index_container. Therefore, my question really is: Is it possible to provide an "unsafe_modify" function, which does the same as "modify" but does not trigger automatic re-indexing, and an "refresh_index" function, which (manually) triggers the re-indexing? Thanks, Deniz