Re: Question on Partition key

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(at)gmail(dot)com> 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(at)ewie(dot)name> wrote:
>
>> On 03/09/2023 00:35 CEST veem v <veema0000(at)gmail(dot)com> 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
>>
>>
>>