[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#9136) mdb index degradation failure



Full_Name: Konstantin Andreev
Version: 2.4.48, git/master/44a7b46/20191203
OS: Solaris 11.3 x64
URL: 
Submission from: (NULL) (79.135.238.172)


When
    * the number of entries containing particular attr/val, e.g. `o=1', reaches
MDB_IDL_DB_MAX+1 ( = 0x10000 = 65536 ), and
    * this attribute is equality-indexed

the index record for this attr/val switches from the enumeration to the range
format ( see back-mdb/idl.c`mdb_idl_insert_keys ).

The only scenario to switch index record back to the enumeration is as described
in the ITS#9135 and probability of this scenario is nearly negligible.

So, the switch to the range format is irreversible and permanent. Moreover, this
range only widens and, with time, tends to eventually extend to the end of the
dit id space.

So, the index record for this particular attibute value gradually becomes
useless.

What makes this issue even worth.

Contrast to bdb, the "range" index records are immortal in the mdb:

 * they offer many-thousand list of search candidates (in terms of mdb_search())
for particular attribute value even if all instances of this value are removed
from the dit.
 * "range" records survive after slapindex
 * they even survive after dropping/creating an index itself

The only way to get rid of the "range" index records and actualize index is to
create a new mdb and populate it from the ground up. This has maintainance
costs.