Actually team have used similar partitioning strategy on integer columns in past. So they are inclined towards that. I will still, double check with others if any business restrictions exists. But as you already mentioned, it's not good in terms of data quality perspective. I agree to this point.
Additionally, is it true that optimizer will also get fooled on getting the math correct during cardinality estimates, as because there is a big difference between , comparing or substracting, two date values VS two number values. And storing the dates in the number columns will pose this problem for the optimizer. Is my understanding correct here?
> We are trying to create a monthly range partition table , partitioned on > column PART_DATE. This will hold Orders and part_date is nothing but invoice > date. Some Team mates are asking to use the "PART_DATE" column as data type > "INTEGER" with "YYYYMM" format [...]
Why do your team mates favor integer over date?
> Want to know experts' views on this. If the data type of the partition key > matters here or not?
Both integer and date are stored as 4 bytes. There should be no difference regarding index size. I don't know if the data type makes a difference in partition pruning performance in this case, but I'd be surprised if it were the case.
> Or if there is any downside of each approach in future?
The downside of integer is that it allows invalid dates (e.g. 202313) unless you also add check constraints. But then just use date if you want to store dates. You get input validation and can use the date operators and functions that Postgres offers.
