Re: IDL cache and a mix of index/unindexed attrs in a query

[Howard Chu <hyc@symas.com>]

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.

--
  -- 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/