You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2013/11/02 23:39:26 UTC

Mavibot Partition

Hi,

today, I investigated the way the Mavibot Partition is implemented, wrt
to the modifications I've made those past month. There are a few missing
parts, I'm afraid.

First of all, we aren't counting correctly. When we add a <key, value>
tuple, we should increment the counter regardless the fact the key
exists or not. In other words, we count tuples, not keys. That's easy to
fix.

A bit more complex : when we create a cursor on top of an index, we
should be able to browse all the tuples back and forth. That means we
should iterate over the keys, and over the values for each key if we
have more than one. It requires some modifications in the way we have
implemented the MavibotCursor. Typically, we have to retain the position
in the BTree, *and* the position in the values associated with the key
we are processing. Currently, it does noy work well.

I'm going to get it fixed.

Thanks for any comment on those findings.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 


Re: Mavibot Partition

Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 11/3/13 3:32 AM, Kiran Ayyagari a écrit :
> On Sun, Nov 3, 2013 at 4:09 AM, Emmanuel Lécharny <el...@gmail.com>wrote:
>
>> Hi,
>>
>> today, I investigated the way the Mavibot Partition is implemented, wrt
>> to the modifications I've made those past month. There are a few missing
>> parts, I'm afraid.
>>
>> First of all, we aren't counting correctly. When we add a <key, value>
>> tuple, we should increment the counter regardless the fact the key
>> exists or not. In other words, we count tuples, not keys. That's easy to
>> fix.
>>
>> I think we should count the tuples, say we have a filter
> (&(cn=x)(sn=y))
>
> and 'cn' index has: x -> 1,2,3,4,5,6,7
> 'sn' index has: y -> 2,5
>
> then the optimizer will pick up the predicate with less number of candidates
> which is 'sn' here based on the count of tuples, if we count only keys
> then this optimization will not work

Absolutely. I fixed the code to count tuples, not keys.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 


Re: Mavibot Partition

Posted by Kiran Ayyagari <ka...@apache.org>.
On Sun, Nov 3, 2013 at 4:09 AM, Emmanuel Lécharny <el...@gmail.com>wrote:

> Hi,
>
> today, I investigated the way the Mavibot Partition is implemented, wrt
> to the modifications I've made those past month. There are a few missing
> parts, I'm afraid.
>
> First of all, we aren't counting correctly. When we add a <key, value>
> tuple, we should increment the counter regardless the fact the key
> exists or not. In other words, we count tuples, not keys. That's easy to
> fix.
>
> I think we should count the tuples, say we have a filter
(&(cn=x)(sn=y))

and 'cn' index has: x -> 1,2,3,4,5,6,7
'sn' index has: y -> 2,5

then the optimizer will pick up the predicate with less number of candidates
which is 'sn' here based on the count of tuples, if we count only keys
then this optimization will not work

> A bit more complex : when we create a cursor on top of an index, we
> should be able to browse all the tuples back and forth. That means we
> should iterate over the keys, and over the values for each key if we
> have more than one. It requires some modifications in the way we have
> implemented the MavibotCursor. Typically, we have to retain the position
> in the BTree, *and* the position in the values associated with the key
> we are processing. Currently, it does noy work well.
>
> I'm going to get it fixed.
>
> Thanks for any comment on those findings.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
Kiran Ayyagari
http://keydap.com