Thank you so much for the clarification.
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?
On Sun, 3 Sept, 2023, 2:02 pm Deep, <biswachk@xxxxxxxxx> wrote:
Have your friends also mentioned how it is going to help to convert date field to integer !???On Sun, Sep 3, 2023 at 3:51 AM Erik Wienhold <ewie@xxxxxxxxx> wrote:On 03/09/2023 00:35 CEST veem v <veema0000@xxxxxxxxx> wrote:
> 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.
--
Erik
