Does the partition key also have to be part of the primary key? I am partitioning a table based on a column that is not a primary key?  I've read some conflicting information today on whether the partition column must be a part of the primary key.  My gut says no, but I am not 100% sure.  So questions...


Must the partition column be part of the primary?  Is it recommended one way or the other?
Do I have to create an index for the partition key, or does the DBMS do it automatically on its own?
Not at all.

One of the most common scenarios for partitioning is to use a date field, which is totally unrelated to your PK.

For instance, if you have a table Orders with the field OrderDate you would most likely partition based on the month and year of OrderDate.  

When records age out and are no longer relevant you can move those partitions off to an archive table or database so they are no longer processed.

Partitioning will work with pretty much any field, but in order for it to work WELL the field(s) you partition on should be used in most, if not all, of your queries.  If you don't include your partition keys then you will get essentially an expensive table scan that goes across multiple tables (partitions).

EDIT

For part 2, I think the answer is no as well.  The partition key is used to determine which partition to put the row in, but I don't think an index is maintained.  There may be stats in the back end on it though.