Hi, Petr, You are on the right track. The file tests/setqgen.cpp is essentially doing what you are talking about. You can take a look at the file either in the source code directory or online at <http://goo.gl/D1XgX>.
The class ibis::table (for a data table) is a container of ibis::part (for a data partition). A table can have multiple partitions. All data records written by setqgen.cpp can be regarded as one table, but it might have a number of partitions. The function ibis::table::buildIndexes calls ibis::part::buildIndexes on each data partition it has. The actual work is done belong ibis::part::buildIndexes. If you are not using ibis::table::buildIndexes, you will be doing the looping yourself. Either way is fine. Take the option that is convenient for you. Good luck. John On 3/8/12 8:10 AM, Thorgrin wrote: > Hi John, > > thank you for your ongoing work on fastbit library, the improvements are > great. > > I have a several question regarding correct usage. We are currently > creating fastbit data partitions using tablex object in following > manner: > > # initialise partition with columns > tablex->addColumns(); > > tablex->reserveSpace(); > # multiple calls to append data. We are storing the data on the fly as > is comes, so there are lots of calls to append. > tablex->append(); > > # When we fill the reserved space, we write the data to disk > tablex->write(); > tablex->clearData(); > > # And continue with > tablex->append() > . > . > > Is this the right and efficient way? Or could you recommend a better > approach? We really just need to receive data and store it into the > partitions fast. Currently it seems that this consumes quite a lot of > CPU resources, just for writing thins down. > > Additionally, we want to created indexes on the newly created > partitions. Currently we load it as a table using > table = ibis::table::create(); > # and then > table->buildIndexes(); > delete table; > > I've noticed that there is a buildIndexes() function on part class. > What is the difference? Should we use the other one? Additionally, > table allows to build an index on specific columns, part only on all > columns. Is there a reason for this? > > Thank you, > Petr _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
