Howard, Howard Chu wrote: > Michael StrÃder wrote: >> Howard Chu wrote: >>> Obviously, for any database that has been around for even a short while, there >>> will be far fewer records with a date newer than [today's date] as opposed to >>> older than then. >> >> But there were only three entries matching >> (reqDN=cn=Test-Mail-Gruppe 1,dc=example,dc=com) >> anyway and reqDN is also eq-indexed and finding them with this filter is >> pretty fast. thanks for your explanations but I still do not fully understand it. Maybe I'm overviewing something obvious. >> Some more examples where reqDN-index is obviously not used but reqStart-index >> should be used in both cases: >> >> Quite fast although I would have expected an significant slow down because of >> negation filter: >> (&(reqDN:dnSubtreeMatch:=ou=Groups,dc=example,dc=com)(reqStart>=20120313072338Z)(!(reqStart>=20120413075657Z))) >> > > Range lookups are expensive, even when fully indexed, but negations bypass all > index lookups, and are simply replaced with (All IDs). Since this is an AND > filter, that result is essentially a no-op and costs nothing. Do I understand you right that in this case reqStart-index is not used at all for processing the part (!(reqStart>=20120413075657Z)). That meets what I expected from negations. But reqStart-index is used for filtering based on (reqStart>=20120313072338Z)? >> Almost identical but very slow compared to the example above: >> (&(reqDN:dnSubtreeMatch:=ou=Groups,dc=example,dc=com)(reqStart>=20120313072338Z)(reqStart<=20120413075657Z)) > >> I can't explain this based on index configuration. Maybe there's something >> handled differently with<= compared to>=? > > They are handled identically, it is simply the difference in number of records > that need to be read. > > On an indexed <= lookup, the backend reads the Equality index of the given > attribute, starting at the beginning, and adding every entryID to the > candidate list, until it reaches the end time. On an indexed >= lookup, it > reads from the specified timestamp to the end of the index. But why does (reqStart>=20120313072338Z) not already limit the number of search candidates to be filtered with (reqStart<=20120413075657Z)? Is filter order significant? But I really wonder why if I use exact reqDN search with reqDN being eq-indexed is slow with additional <= filter part. Fast since reqDN eq-indexed and only one(!) entry returned: (&(reqDN=cn=Info-Mail-Testgruppe1,ou=Groups,dc=example)) Fast since reqDN and reqStart eq-indexed: (&(reqDN=cn=Info-Mail-Testgruppe1,ou=Groups,dc=example)(reqStart>=20120313072338Z)) Slow (30 sec) although reqDN eq-indexed which should already limit the number of search candidates to one(!): (&(reqDN=cn=Info-Mail-Testgruppe1,ou=Groups,dc=example)(reqStart>=20120313072338Z)(reqStart<=20120415075657Z)) Aaah, now I see. If I turn off eq-index for reqStart this case is also fast because first the reqDN-eq-index is used and after that unindexed filtering is done on reqStart range. Hmm, can I influence the order of index usage by order in the filter or slapd index configuration? Wouldn't it make sense to treat <= filter parts as unindexed even if there's an eq-index defined for the attribute type to postpone <= filtering to the set of search candidates filtered by indexes before? Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature