I have a table like this one:

```
CREATE TABLE "TS1" 
       (    
        "ID" VARCHAR2(32 BYTE) NOT NULL, 
        "CID" VARCHAR2(70 BYTE) NOT NULL, 
        "PID" VARCHAR2(21 BYTE) NOT NULL, 
        "LASTUSAGE" TIMESTAMP (6) NOT NULL, 
        "CREATIONTIME" TIMESTAMP (6) NOT NULL, 
        "COSTCENTER" NUMBER NOT NULL
       );

ALTER TABLE "TS1" ADD CONSTRAINT "TS1_PRIMARY" PRIMARY KEY ("ID", "CID", "PID");

```

I tried to find a good way to partition the table considering:

* I have no query that use creationTime in where clause ( So range partition maybe is not the best solution on this field)
* LastUsage is updated very often (so range partition maybe is not the best solution on this field)
* Most of the queries uses ID, CID, PID in where clause

So standing this, a good option should be HASH PARTITION on ID,CID,PID.

```
CREATE TABLE "TS1" 
       (    
        "ID" VARCHAR2(32 BYTE) NOT NULL, 
        "CID" VARCHAR2(70 BYTE) NOT NULL, 
        "PID" VARCHAR2(21 BYTE) NOT NULL, 
        "LASTUSAGE" TIMESTAMP (6) NOT NULL, 
        "CREATIONTIME" TIMESTAMP (6) NOT NULL, 
        "COSTCENTER" NUMBER NOT NULL
       )       
PARTITION BY HASH ("ID", CID, PID)
PARTITIONS N;  --N = number of partitions

ALTER TABLE "TS1" ADD CONSTRAINT "TS1_PRIMARY" PRIMARY KEY ("ID", "CID", "PID");

```

Is it a problem if I'm partitioning by hash using the primary key as parameter?
Let's suppose to have lot of records in table TS1 (millions) I will receive some perfomance benefits from this partitioning?