Quanah Gibson-Mount wrote:
I'm never 100% sure I understand how the idl cache works, but as I understand it, it caches the index keys of common searches, where the attributes are indexed. Assuming my understanding is correct, my question has to do with how things behave when some of the attributes are indexed, and some aren't. For example, assume:
a - indexed eq, a match only returns a single entry in the DB b - unindexed, only has one possible value if present c - unindexed, only has one possible value if present
A query of (&(a=x)(b=y)(c=z)) performs very quickly because the a=x filter is applied first, and locates the object, with the remaining pieces of the filter being applied to the entry that was found. My question is, does this query end up in the IDL cache?
"Queries" aren't cached; index keys are.
I played around with this somewhat, and I see no difference in search times between:
(a=x) (&(a=x)(b=y)) (&(a=x)(by=y)(c=z))
In this usage case, then, is there really any benefit to indexing b & c?
No. That's totally orthogonal to the IDL cache though.
The DB backends execute a search in two phases, first is generating a candidate list for the filter from the index, and second is iterating through the candidate list to test each candidate entry to see if it actually matches the filter. If you have a filter term that produces a single candidate from the index, then since you're ANDing filter terms, the resulting candidate list can only be zero or one entries long, regardless of any other indexing. So in this case, you'd save memory and update times by leaving the other attributes unindexed.