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!
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@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp