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.