I believe what you are asking above is actually more table design. Partitioning in DB2 has a very specific meaning. However, given that you are worried about performance, it is apropos to discuss DB2 partitioning and what it means.
To start with there are two types of partitioning in DB2:
- Table Partitioning
- Database Paritioning
There is also another form of partitioning known as Multidimensional Cluster Tables (MDCs). More on MDCs later.
Table Partitioning allows you to divide a table internal to DB2. It will store data grouped/divided by a particular partitioning scheme. A common way to partition is based on some date. For example you may partition based on year. Essentially this is like having the same table definition over and over again (though not really), but each "table" has only the data related to that particular partition key. Indexes written over table partitioned tables, get "split" in the same way. This allows for great flexibility. Depending on the data you are querying/updating, DB2 will optimize and only visit the indexes and table partitions that fall within the ranges of your data in question. This essentially means less I/O (thus less CPU and memory). You get table partitioning for "free" within the Enterprise Edition of DB2. From what I understand you can choose to use table partitioning after a table is created. You just have to alter the table and tell it to re-distribute the data (which is a cost to time, resources, and locks) but it is do-able.
Database Partitioning is similar, but more along the lines of having load balanced servers. You can declare a database partition group across multiple servers. When you create a table you specify which partition group (or even partitions) to place it in. And once again, you specify a partition key. This will split the table up between the physical servers (or database partitions). And once again, DB2 will optimize your query/update based on the criteria in your SQL. It will know on which server (or servers) your data is residing on. This allows for a spread of CPU, memory, and I/O utilization across several physical servers. (Again, think load balancing here.). Note that table must be declared in a partition group if you want to use this (otherwise I believe it defaults to the partition you are currently working on and it will only place the table on that partition). But the benefit of placing it in a group is that as you add/remove partitions, you can tell DB2 to re-partition the data and it will spread it out accordingly based on what is available to it (though again, re-distribution is a cost). Database partitioning is only available via the Database Partitioning Feature (aka DPF). Though included with the binaries for DB2 Enterprise Edition, it is a separate license that needs to be purchased to enable this.
Multidimensional Clustering Tables (MDCs) allow for another form of "partitioning" data. They allow you to build data using a block cluster index structure (say clustering on sales territory). DB2 will create the table and specify a huge chunk of disk as "blocks" and write data related to the clustering key to that block. Updates are technically less expensive than a traditional index as it does not need to know the RID of the location on disk. It only needs to the know the block ID that the data is stored in. This allows for very fast efficient retrieval of lots of data. Because of this, MDCs are most often used in data warehouses and data marts (though they can also be used in OLTP environments) as they return larger amounts of data through less I/O. The key here is clustering on the right columns (unlike traditional indexes where you want high cardinality, you actually want lower cardinality for MDCs to insure less I/O as you want to retrieve larger "chunks" of data). Note that a table MUST be declared as an MDC up front. You can't change a table to MDC after it is created. MDCs are available for "free" in Enterprise Edition.
The nice thing about each of these three features is that they are independent of each other and thus you can use each. For example, I could create a MDC clustered on sales territory, table partition it based on year, and then place it in a database partition group (partitioned on hash, ie an internal hashing id mechanism DB2 uses) across all database partitions.
Now depending on my query, only the CPUs, memory, and disk necessary will be used to retrieve my data. This can free up resources for more work as each piece is doled out only to the necessary hardware components.
Now, with what I all said, realize that you don't just want to do all three. That would probably be pre-optimization, which is usually a bad thing. It would be best to try out each option individually first to see what you gain, and then maybe also different combinations. Doing this will take time, but in essence helps to tune your database and engine. Take your time on it. (also note again, that DPF requires a license fee). If you do figure out that say you need table partitioning and maybe want to move to database partitioning later, it may be a good idea to define a table with table partitioning and then define it in a database partition group (even if that group has only one partition). Then when you add another database partition (server) to the group, you can tell DB2 to redistribute the data and pick up the benefits of the other server. Thus scaling out that way.
But again, don't just do these things for the sake of doing them. Take them into account with table design changes and test these in other environments under load conditions, etc. so you understand both the complexity of setting them up as well as the benefits of each.