Re: Performance issue after creating partitions

In this type of situation, I would have a column of type date for the
partitioning and another one for the timestamp. The additional space will
surely be marginal but the gain in performance really significant.

Another thing you could try is to add a computed index on
trunc(order_date): an index scan would move less data than a table scan.

Olivier Gautherot

Le jeu. 25 août 2022, 00:41, Teja Jakkidi <teja(dot)jakkidi05(at)gmail(dot)com> a
écrit :

> Hello Admin team,
>
> We have a Postgres 13 server set up on Google Cloud. Recently we created
> partitions as below for the tables:
> Range on ‘order_date’ column
> List on ‘country_code’ column
>
> Quarterly partitions for range.
>
> Order date column is a time stamp column and when we are using this column
> as a filter in where condition : trunc(order_date) =
> to_date(’2022-04-01’,’YYYY-MM-DD’), the query scans all the partitions
> dated back from the year 2000. So, instead of going to the 2022 Q2
> partition directly, the query is scanning all the partitions.
> But when we remove the trunc() function and just specify order_date
> =‘2022-04-01 07:02:30’, this works as expected. It goes to the correct
> partition directly and gets the data.
> Can Anyone help me on what’s happening in the first case and why all the
> partitions are being scanned?
> For the first case, when there is a non partition table, it is behaving
> way better.
>
> Thanks,
> J. Teja.
>
>