Univention Bugzilla – Bug 40567
index: remove / reduce "pres" indexes
Last modified: 2024-04-12 17:49:55 CEST
according to OpenLDAP documentation it makes no sense to have "pres" indexes for most use cases. We should review that and remove them from the default if possible. from http://www.openldap.org/doc/admin24/tuning.html --------------- 21.2.3. Presence indexing If your client application uses presence filters and if the target attribute exists on the majority of entries in your target scope, then all of those entries are going to be read anyway, because they are valid members of the result set. In a subtree where 100% of the entries are going to contain the same attributes, the presence index does absolutely NOTHING to benefit the search, because 100% of the entries match that presence filter. So the resource cost of generating the index is a complete waste of CPU time, disk, and memory. Don't do it unless you know that it will be used, and that the attribute in question occurs very infrequently in the target data. Almost no applications use presence filters in their search queries. Presence indexing is pointless when the target attribute exists on the majority of entries in the database. In most LDAP deployments, presence indexing should not be done, it's just wasted overhead. See the Logging section below on what to watch our for if you have a frequently searched for attribute that is unindexed. ---------------
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
There is a Customer ID set so I set the flag "Enterprise Customer affected".
(In reply to Ingo Steuwer from comment #0) > according to OpenLDAP documentation it makes no sense to have "pres" indexes > for most use cases. > from http://www.openldap.org/doc/admin24/tuning.html > > --------------- > 21.2.3. Presence indexing > > If your client application uses presence filters and if the target attribute > exists on the majority of entries in your target scope, then The important condition here is "AND if the target attribute exists on the MAJORITY of entries". It does not make sense to filter for `(objectClass=*)` as that matches *ALL* entries, but `(sOARecord=*)` with a selectivity of <1% makes much sense.