Hello A S,
properly partitioning tables is an art form (on pretty much any DB platform). It's always a trade off. So my going in position is not to partition anything... And then you start looking at limitations... SAP HANA has a limitation of 2 billion records per partition... Any table bigger you have to deal with... And then you notice that you have many more CPU on other nodes.... SAP HANA can use them with a single table only if the table is partitioned and distribusted across the nodes... And then you realize than you don't want to deal with this for so many of your big tables... You can do it manually with SAP HANA... or you can use some pretty good default settings if you are running SAP NetWeaver BW on top of SAP HANA (on of the benefits of BW over standalone data marts ;-) ).
Anyway, nothing really new to you. The point is to keep it simple and automated as much as possible and step into manual tuning and partitioning only when necessary. If you are able to determine user behaviour upfront, then usually you can come up with a good range partitioning which takes advantage of pruning. If it's mostly ad-hoc queries, then hash partitioning is the way to go.
Regards,
Marc
SAP Customer Solution Adoption (CSA)