[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Can I remove an existing index?
- To: openldap-software@openldap.org
- Subject: Can I remove an existing index?
- From: Ole Nomann Thomsen <ont@uni-c.dk>
- Date: Thu, 13 Sep 2007 12:05:53 +0200
- User-agent: Mozilla/5.0 (X11; U; Linux i686; da; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666
Hi list. I have a question about an ldap-base that I maintain
The base contains about 500,000 records with attribute uid (single value
and unique) and code(multi value; typically between 10 and 200 values,
5-50 bytes or more each, not unique). The code attribute is indexed on
eq and sub for historical reasons, but the index is no longer needed (if
it ever was). The uid attribute is, and will stay, indexed on eq.
Tests reveal that updating records can be time consuming when they
contain a large number of long codes, sometimes about 1.25 seconds pr.
record(!). In contrast to this, when I update without the index, I get
around 75 recs/second. Searching is still fast, as I never search for
code without uid.
So I'm going to drop that index, no doubt about it. The reliable method
would be to slapcat-reconfigure-slapadd of course, but that will cost
lots of planning and timing (the base is replicated on 3 servers, and is
constantly updated, 2 servers must be available at all the time). It is
feasible, but it *will* be a pain.
So: Can't i simply drop the index from the config file, restart, and
thats it? That is, remove the line:
index code eq,sub
And perhaps the code.dbb file from the database directory? Perhaps
slapindex too?
Further tests indicate that it works, lookups, updates and everything
seem OK. But there is a worrying warning in the logfile:
2007-09-11 12:09:53.742266500 <= bdb_equality_candidates: (code)
index_param failed (18)
The warning persists after slapindex, but is not there when I search for
attributes that was "born" without an index.
So will it break eventually? Or do I need to tell the backend something?
Background (as much as I can dig up, perhaps too much):
OpenLDAP: slapd 2.3.25
Backend: back_bdb, vers 4.2 (Berkeley DB, Btree, version 9)
Linux: Debian 2.6.18
Sears filter (always): "(&(uid=...)(code=...))" (experimentally shown to
work fine without index on "code")
And the same question for:
OpenLDAP: slapd 2.2.26
Backend: ldbm (Berkeley DB, Btree, version 8)
Linux: Mandrake Linux 9.0 3.2-1mdk
Sears filter (always): "(&(uid=...)(code=...))"
Thanks for reading this far :-) and for any answers.
- Ole Thomsen