is it better to drop secondary indexes before truncate

Detail

is it better to drop secondary indexes before truncate?

Is this bug relevant:AER-6526: (SINDEX) Truncating a namespace or set with a secondary index, and more than 2 billion records per node, may overflow a garbage collection queue and crash.

Answer

Before 5.7, you had to drop sindexes before truncating. If you did not, there could be a sindex memory leak if later re-created records had different bin values. This was because the sindexes were digest-based – the Garbage Collection (GC) process would pass over the entries with old bin values, since it was just checking record existence via lookup of digest in the primary index, satisfied by the re-created record.

At 5.7, you no longer had to drop sindexes before truncating. The memory leak issue was gone.  This was because the sindexes were no longer digest-based – re-created records could now easily be distinguished from the deleted ones during GC.

In general, if sindexes are big, it is still faster to drop sindexes before truncating. The only downside to dropping sindexes before truncating is that you have two extra operational steps – dropping the sindexes, and re-creating the sindexes. If the sets/sindexes are small, you might not care about the overall speed, and so just truncating is more convenient.  Issue truncate when the sindexes are completely destroyed and then re-create the sindexes when the truncate background process is done. Also assuming no write load to the set during all this time. Resume write load once the operations is completed.

Regarding AER-6526, it is better to drop sindexes before truncating. If you don’t drop sindexes before truncating, it is still only likely to be a problem with a flash primary index, and then only when using a version prior to the latest hotfixes for 5.7, 6.0, and 6.1.

With sindex in shmem in 6.1 and later, it should be more efficient not to drop sindexes.

Notes

Applies To Earliest Version

Applies To Latest Version