PPI or NUSI? - response (1) by dnoeth

If you add a yr_mon column you probably keep your date column resulting in doubling the diskspace, 4 (date) -> 8 (date+int) bytes.
If users want to access a year they still have to write a condition like BETWEEN 201201 and 201212. If you don't want your user to deal with some basic calculation like BETWEEN DATE '2012-01-01' and DATE '2012-12-31' you might easily hide that month-begin/end calculation in a SQL-UDF: BETWEEN month_begin(201201) and month_end(201201).

 
We were planning to make yr_mon as PPI of this new table but as we know that in order to make the queries efficient pi and ppi should be used together in order for the faster retreival however in this case User would only be knowing the month and year for querying hence there would be a redistribution in absence of PI in queries,hence not going for PPI.
 

This is a confusing sentence, especially without any punctuation. 
When the partitioning column is used in the WHERE-condition you get partition elimination regardless if it's part of the PI or not.
But PI-access/joins without additionally specifying the partitioning might be slower (much slower when the number of partitions is large).
"redistribution" is totally independant of that.
 
The selectivity of a NUSI on yr_mon is quite low, the optimizer will probably not use it.
 
 
Dieter