maria-developers team mailing list archive

[Richa Sehgal <richasehgal2908@xxxxxxxxx>]

Thanks Sergei and Nirbhay!

I have managed to install Maria. Then I wanted to start working on
understanding virtual columns and index in the code, and decided to run it
in gdb. That was pretty tricky until I saw the page for ptrace() permission
on Ubuntu. The knowledge base is pretty good :)

I put a breakpoint in the functions _mi_make_keys() and
update_virtual_fields(). I then ran sql commands on the mariadb terminal to
create tables with virtual persistent columns and also inserted values. At
each of these, my breakpoint in the function update_virtual_fields was hit,
but not at _mi_make_keys().

I Googled a bit, and saw this: MyISAM was the default storage engine from
MySQL 3.23 until it was replaced by InnoDB in MariaDB and MySQL 5.5. on
this page:

https://mariadb.com/kb/en/mariadb/myisam-storage-engine/

I guess that MyISAM is no longer used by default and that's why breakpoint
in _mi_make_keys was never hit. So I have two questions to proceed with
this GSoC project:

1. In the GSoC, would we still concentrate on MyISAM? If not, can you
please guide me and give me the function that constructs the key in InnoDB
code?
2. I tried specifying the engine = myiasm on the terminal using this link
on mysql http://dev.mysql.com/doc/refman/5.1/en/storage-engine-setting.html
But this didn't help. I believe we have to change some setting in the
config file?

I request you to guide me to the next step. From my side, I am working hard
to understand the code base and playing with it in GDB and through terminal.

Thanks
Richa

On Sun, Mar 15, 2015 at 2:31 PM, Nirbhay Choubey <nirbhay@xxxxxxxxxxx>
wrote:

>
>
> On Sun, Mar 15, 2015 at 7:48 AM, Richa Sehgal <richasehgal2908@xxxxxxxxx>
> wrote:
>
>> Dear Sergei and Maria community,
>>
>> Finally I have settled on one project: Indexing over virtual columns.
>>
>> I spent the entire day today trying to compile MariaDB in Ubuntu and
>> reading the code. On reading code side, I spent some time in the
>> /storage/myiasm/ : read fiels like mi_key.cc, mi_create.cc, ha_myisam and
>> so on. Took a brief overview arounf _mi_make_key function. I also looked
>> around update_virtual_fields() function.
>>
>> The code path is still not very clear to me - especially the transition
>> point between sql folders to /storage folders. I chatted on #maria IRC and
>> they gave an idea to run Maria in gdb mode. I tried compiling the code  it
>> was almost successful! At the very final step, I got the following error:
>>
>> [ 98%] Built target thr_lock
>> Linking CXX shared library libmysqlclient.so
>> /usr/bin/ld: error: /home/shikhar/mariadb/maria/trunk/libmysql/libmysql_versions.ld:155:9:
>> invalid use of VERSION in input file
>> collect2: ld returned 1 exit status
>> make[2]: *** [libmysql/libmysqlclient.so.18.0.0] Error 1
>> make[1]: *** [libmysql/CMakeFiles/libmysql.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> I am not able to proceed now. I tred googling around, but could not find
>> the fix. Can you please guide me in my next steps?
>>
>
> I think you hit the ld/gold issue.
> https://mariadb.atlassian.net/browse/MDEV-5982
>
> Best,
> Nirbhay
>
>
>> Thanks
>> Richa
>>
>> On Sat, Mar 14, 2015 at 10:46 AM, Sergei Golubchik <serg@xxxxxxxxxxx>
>> wrote:
>>
>>> Hi, Richa!
>>>
>>> On Mar 14, Richa Sehgal wrote:
>>> > Thanks Sergei for the explanation. The modified project for MDEV-5199
>>> > (Table Functions) now makes sense - as in the proposals mentioned in
>>> the
>>> > ticket as possible solutions now looks appropriate :)
>>> >
>>> > I am looking into the index of virtual columns. One question: can we
>>> submit
>>> > proposals for 2 projects at MariaDB?
>>>
>>> We don't mind, but rules are set by Google, if they allow it - you can,
>>> otherwise you cannot.
>>>
>>> > Now as for Table Functions:
>>> >
>>> > As mentioned there are two ways:
>>> > 1. Materializing the table - this has a disadvantage for extra space.
>>> > 2. Treating the UDF result as an "abstract table". For eg, the code
>>> might
>>> > have a base class called Table. Then we can create a derived class
>>> called
>>> > UDFTable and pass this instance in the regular query processing. This
>>> class
>>> > would implement all functionalities like Init(), Next(), Read(int
>>> > col_index), Seek(), etc
>>> > Consider:
>>> >  Select A where A.x > 10 FROM UDF_TABLE
>>> >
>>> > In this case, we will first construct the table UDF_TABLE through
>>> regular
>>> > query - evaluation of the UDF. Then we can create an instance of
>>> UDFTable
>>> > from the table and run normal query processing on this.
>>> >
>>> > Is this the right approach? Can you send me the next steps?
>>>
>>> the "abstract table" that can do Next, Read, Seek, etc in MariaDB is
>>> represented by the "handler" class. All real storage engines inherit
>>> from the handler class.
>>>
>>> See the SEQUENCE engine, it's in the storage/sequence/sequence.cc
>>> This is, exactly, the engine that generates data on the fly, so is a
>>> table function, in a sense. But it's a hard-coded function and the way
>>> of passing arguments is not very nice. Still, it'll give you an idea
>>> what a table function handler might look like.
>>>
>>> If you want an even simpler storage engines - there are some in our
>>> book, "MySQL 5.1 Plugin Development".
>>>
>>> Regards,
>>> Sergei
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~maria-developers
>> Post to     : maria-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~maria-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>