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? Thanks Richa On Sat, Mar 14, 2015 at 10:46 AM, Sergei Golubchik <[email protected]> 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 : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
