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