On Sun, Mar 15, 2015 at 7:48 AM, Richa Sehgal <[email protected]> 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 <[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 > >
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
