ordering indexing

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

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga

> A couple of thoughts (mostly food for thought)...
>
> This will obviously cause a serialization of directory
> updates within the context and contention on the lastmod
> entry.  I think it would be offer a version which didn't
> back the lastmod entry into the database.  One could even
> address persistency issues by determining the values from
> the entries at start up, instead of relying on the backing.
> If we had ordering indexing, determination would be quick.

Speaking of which... I never found any order-preserving hash functions that I
could see being generally applicable here, but we could certainly do some
indexing for specific syntaxes that represent timestamps and other limited
size/range values. (I.e., we can crunch their normalized value directly into
a 32 or 64 bit integer losslessly.)

One gotcha here is that we would need to avoid overlapping/clashing with the
current hashed index key space. It kinda implies resurrecting the use of
subdatabases, which may not be a safe thing to do. Thoughts?

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