On Tue, Aug 16, 2011 at 6:45 PM, Stefan Seelmann <[email protected]> wrote:
> On Tue, Aug 16, 2011 at 2:22 PM, Kiran Ayyagari <[email protected]> wrote:
>>> One solution would be to store two more elements in the ParentIdAndRdn data
>>> structure : the number of children directly below the RDN, and the number of
>>> children and descendant. That would probably solve the issue I'm mentioning.
>>> Of course, that also means we wil have to update all the RDN hierarchy from
>>> top to bottom (but affecting only the RDN part of the entry DN) each time we
>>> add/move/delete an entry. Note that we already do that for the oneLevel and
>>> Sublevel index.
>>>
>> Just to make a point:
>> I think, in the case of achieving SubLevel index evaluation with RDN
>> index it becomes a costly and complex operation
>> (recursive scanning and updating) where as with the current sublevel
>> index it takes O(1) to fetch all the sublevel children of
>> an entry.
>
> Hm, evalutation can easly be done by using the reverse RDN index table.
>
for one level it is straight forward, but for sublevel we still need
to use recursion, no?


-- 
Kiran Ayyagari

Reply via email to