Hi Mikhail,
For COLUMN tables, you can get around the 2 billion row limit for the table by setting up a partition. Generally, you'll do this across a multi-node cluster for the best performance. Regarding Gary's solution for generating the data this way, this is not likely to be representative of real data as the fact table will have less unique values and will result in a great compression ratio. This is why I like the TPC-DS benchmark over the TPC-H benchmark. TPC-H goes too far in generating unique values for the fact table. On the other hand, more thought by the committee went into the DB design and data generation to be more real-life. More importantly, you can really crank up the size of the data set. Check out this great read on the making of the TPC-DS benchmark - http://www.vldb.org/conf/2006/p1049-othayoth.pdf and http://www.tpc.org/tpcds/presentations/tpcds_workload_analysis.pdf. You can find the generator at http://www.tpc.org/tpcds/default.asp and look for the DSGen link. Note, it's critical to use the scale factors designated for official benchmark runs that creates both query files and the data files. If you don't, the DSGen program errors out. There is a scale factor of 1 available for a 1GB of data for getting the queries right. You can then crank it up to 100GB, 300GB, 1TB, 3TB, 30TB and 100TB.
TPC-DS is a brutal benchmark - notice no vendors have published results yet for it. It's not possible for a pure columnar database to game this benchmark, so it requires a engine that can balance ROW and COLUMN tables for the best performance. I'm guessing the HANA dev team in Germany is looking at hard to make this work. :-)
Regards,
Bill