[Date Prev][Date Next]
Re: >= <= filter hangs
There is no support for inequality indexing in the current backends. As
such, filters with inequalities are handled using the presence index.
This means that the server must inspect every entry in your database
that contains the referenced attribute and test them individually. It of
course sends results as soon as they match, which is why you get some
results right away. But it then continues through all the other entries
in the database, which is why you get a long delay before the request
In OpenLDAP 2.3 back-bdb has limited support for inequality indexing. It
is currently only implemented for generalizedTime and
ChangeSequenceNumber syntax. It can probably be supported for a few
other integer-type syntaxes without much pain. It cannot be supported on
syntaxes that support substrings.
Jon Roberts wrote:
Ok, sorry, but another one came up:
RH 9, OL 2.2.5, BDB 4.2.52. Same database.
When I run:
% ldapsearch -x -b ou=Gospel,ou=Expressions,o=mentata.com
I get the usual flurry of all five verses within the first second, but
I don't get the search results info or the cursor back for 23 seconds
more. I'm seeing something similar in my JLDAP clients, only they
don't show the data because they block until the request completes.
Relevant data looks like:
dn: gospid=GVMattC01V06, ou=Gospel, ou=Expressions, o=mentata.com
gospowner: cn=Matthew, ou=Bible, ou=People, o=mentata.com
gospname: Matthew 1:6
attributetype ( 184.108.40.206.4.1.15220.127.116.11 NAME 'gospqualifier'
SYNTAX 18.104.22.168.4.1.1422.214.171.124.44 )
index gospid,gospname,gospqualifier,gospdescription eq,pres,sub
This was very fast in previous software indexing on dnqualifier
attribute from core.schema. I originally tried this with ...1.15
directory string syntax, but alas the same problem. Any hints? I'm
actually hoping this just needs an upgrade.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support