maria-developers team mailing list archive
Mailing list archive
Re: Sachin weekly report
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
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.
On Fri, Jul 15, 2016 at 5:29 PM, Sachin Setia <sachinsetia1001@xxxxxxxxx>
> okay sir, i will just store the is_hash flag and on
> add flag to key. thanks
> On Fri, Jul 15, 2016 at 3:58 PM, Sergei Golubchik <serg@xxxxxxxxxxx>
> > 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@xxxxxxxxxxx