Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (athena.apache.org: domain of ayyagarikiran@gmail.com
 designates 209.85.162.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding;
        b=PdkQzbKKLi1dQqBdw8qAjIc4B2c4IF1c4mi1gQsRC2KIZbj1zrDHJQuG/52PyUYZAquqWeG8YCrdk4vxfHHccqF4vfjoDeFFAXzDQhvj8WxDX+NGgg6yMsqnc3MCAVetZjG4ExVDTGAhabIc3tLJienr+qZVmYRwUxvViDcSOFQ=
Message-ID: <47B0AD54.6000100@gmail.com>
Date: Tue, 12 Feb 2008 01:47:24 +0530
From: Kiran Ayyagari <ayyagarikiran@gmail.com>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071022)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: splay tree for duplicate key cursor implementation
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

hi Guys,

    During a discussion with Alex it was understood that implementing a 
linked
    splay tree for duplicate key cursor may not result in any 
performance gain.

    When we perform lookups on the splay tree (kept in memory after 
fetching the
    serialized version )  its structure changes due to splaying.

    This changed structure will be discarded without writing back to the 
disk to
    eliminate the write cost. This way it will not help us in any form 
to get the amortized
    time benefits.

    So we are thinking of using some kind of btree for the actual 
implementation.

  Thoughts?

- Kiran Ayyagari