RE: Proxycache Documentation - again , . . . .

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo Masarati

> > An important design consideration was to reduce the cost of query
> > containment. Proxy cache is designed to improve performance
> for a subset
> > of queries which belong to specified templates. Thus containment is
> > checked between queries of the same template. Apart from
> reducing the
> > number of filter and attribute set comparisons, it greatly
> simplifies
> > filter containment (at least for conjunctive queries). This
> does result
> > in slightly reduced cache answerability.
>
> Apurva,
>
> I clearly see your point, but Reinhard's consideration
> is really intuitive.  I'm working on query templating
> for a totally unrelated issue, but I'll try to get
> inspiration from your code.  I think the possibiity to
> recognize sub-contained queries should be investigated.
>
> I'll have a look at it.

There are definite tradeoffs to consider here. The actual usefulness of such
a change is limited, given the constraints on the cacheability determination.
If you keep the current cacheability configuration, then only a small
percentage of your queries will keep the cache up to date. The information
will age out despite the other queries that are answerable from it.

If you go to a more free format cacheability decision, (i.e., cache any
queries that match the filter template and any subset of these attributes)
then determining answerability becomes much more expensive.

Consider - if you use an attrset with 20 attributes, then somebody must make
a query requesting all 20 of those attributes before any query data enters
the cache, and somebody must repeat this query on a regular basis to keep the
cache fresh (since we don't use syncrepl yet to refresh it). All the other
queries that only want one or two attributes can only be satisfied after the
20-attr query has been done.

If you change the nature of the cache such that querying for any subset of
the 20 attributes will update the cache, then you have the complex job of
tracking which individual cached queries can answer a given request. You can
reduce the number of comparisons by using sorted attr sets and other such
tricks, but you have to inspect every cached query in the database. (You
could probably index it if you limit attrsets to 32 or less, and use a bitmap
to represent the attrs present in each query.)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support