[Date Prev][Date Next]
Re: IDL cache and a mix of index/unindexed attrs in a query
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
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.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/