
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@mariadb.com> wrote:
On Sun, Mar 15, 2015 at 7:48 AM, Richa Sehgal <richasehgal2908@gmail.com> 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@mariadb.org> wrote:
Hi, Richa!
Thanks Sergei for the explanation. The modified project for MDEV-5199 (Table Functions) now makes sense - as in the proposals mentioned in
On Mar 14, Richa Sehgal wrote: 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp