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.