The index-entry-limit
backend configuration property specifies the
maximum number of entries kept in an index record before the server stops maintaining that
record, begins scanning the whole database, and runs an expensive unindexed
search.
Because composite indexes are much more efficient than exploded indexes when dealing with large numbers of identical keys, use composite indexes for data sets where large numbers of entries (several thousand or more) share the same value for an indexed attribute.
If any index keys have already reached this limit, you must rebuild these indexes before
they can use a new limit. If you configure index-entry-limit
to be greater
than 50000, any keys with more than 50000 entries are stored in a separate database in an
expanded, or exploded, format.
All keys with less than 50000 entries continue to be stored in one database in a
consolidated format so that changes to the key require rewriting all the entry IDs matching
the key. All keys with more than 50000 entries and less than the
index-entry-limit
are stored in a separate database in an exploded
format so that changes to the key require writing to the updated entry ID only.
If you increase the index-entry-limit
to 100000, any key with an entry
count less than 50000 continues to be stored in consolidated format. If a key has an entry
count greater than 50000, it is stored in a separate database where each key is stored with
its entry ID individually. The consolidated format is efficient for read operations because
the server can retrieve a row of entry IDs at once, while the exploded format is efficient
for high volumes of write operations because it avoids large on-disk growth.