Weekly Report for 8 week of gsoc

1 Changed the key flags as suggested by you.
2 Now update will use only one buffer as suggested by you but there was one problem some time offset can be
negative so i changed the field cmp_offset parameter from uint to long
3 Still working on coding conventions.

4 I have made prototype for optimizing where for keys like unique(a) , it is on branch
https://github.com/SachinSetiya/server/tree/unique_index_where

Currently I am working on muliple keys like unique(a,b,c) i think this should take 2-3 days  and edits suggested by you.
Regards
sachin

On Fri, Jul 15, 2016 at 5:29 PM, Sachin Setia <sachinsetia1001@gmail.com> wrote:
okay sir, i will just store the is_hash flag and on init_from_binary_frm_image
add flag to key. thanks
Regards
sachin

On Fri, Jul 15, 2016 at 3:58 PM, Sergei Golubchik <serg@mariadb.org> wrote:
> Hi, Sachin!
>
> On Jul 14, Sachin Setia wrote:
>> Hello Sergei
>> Actually i have one doubt  there is two options
>> 1 add is_hash flag to field
>> 2 add ha_unique_hash flag to field ,but i think all 16 bits of key flag is used
>> so to do this i need to add another ex_flag variable in key struct and
>> store it and retrieve it from frm
>> currently i have done both ,but as you pointed out in review that  it
>> is better to have it in key only but
>> my question is that, whether is this approach is right ?
>
> From the storage point of view, it's much easier to put a special flag
> on the field. You can store it in EXTRA2 or you can store it in the
> Field::unireg_check enum.
>
> And then you recognize your HA_UNIQUE_HASH keys by having is_hash
> property on the field of the first keypart. You can even set the
> HA_UNIQUE_HASH flag in the key, if HA_UNIQUE_HASH=65536, for example.
> That is, it won't be stored in the frm, and you set the flag in
> init_from_binary_frm_image - the flag can be used to simplify run-time
> checks, but it won't be stored on disk.
>
> Regards,
> Sergei
> Chief Architect MariaDB
> and security@mariadb.org