From: Teja Jakkidi <teja.jakkidi05@gmail.com>
To: Doug Reynolds <mav@wastegate.net>
To: gogala.mladen@gmail.com
Cc: pgsql-admin <pgsql-admin@lists.postgresql.org>
Subject: Re: Performance issue after creating partitions
Date: Tue, 30 Aug 2022 14:21:50 -0700
Message-ID: <6F2BE85B-F6D0-4D4C-9DEA-EEE09D97B8EF@gmail.com> (raw)
In-Reply-To: <738BC8F9-5F1E-4E8F-8EB9-DEE6EDAA740B@gmail.com>
References: <738BC8F9-5F1E-4E8F-8EB9-DEE6EDAA740B@gmail.com>
Anyone ever encountered the below situation as what I am noticing with partitions?
Thanks,
Teja. J.
> On Aug 26, 2022, at 11:46 AM, Teja Jakkidi <teja.jakkidi05@gmail.com> wrote:
>
> Thank you, Doug and Malden for your inputs.
>
> As suggested by Doug I tried replacing the trunc() with below command:
> “ order_date >= to_date(..) and order_date < to_date(..) + interval '1' day”
>
> What happens here is: My query has 2tables : A and B, both are having an inner join on company code and order date. We have A.Company_code, A.order_date filter in the where condition which was having trun() previously but now I replaced it with the command suggested by Doug. The company_code filter is working for both tables A and B, the query is searching only the partitions particular to that country code. However for order_date condition, the partitions for A table are being utilized correctly I.e the query is searching directly in only one partition based on that date. But for table B, it is still searching all the partitions, it is not applying the where A.order_date condition for B tables partitions while searching.
> I do not understand why the A.order_date filter is not being applied to table B where as A.company_code is being applied to both tables.
>
> Thanks and Regards,
> J. Teja Sri.
>
>> On Aug 24, 2022, at 5:52 PM, Doug Reynolds <mav@wastegate.net> wrote:
>>
>> You need to change your query to not use the trunc. The TRUNC statement forces it to trunc every row in the table.
>>
>> If you do order_date >= to_date(..) and order_date < to_date(..) + interval '1' day, it will use the partition range to narrow down to the correct partition first.
>>
>> Sent from my iPhone
>>
>>>> On Aug 24, 2022, at 6:41 PM, Teja Jakkidi <teja.jakkidi05@gmail.com> wrote:
>>>
>>> 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.
>>>
>>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: teja.jakkidi05@gmail.com, mav@wastegate.net, gogala.mladen@gmail.com, pgsql-admin@lists.postgresql.org
Subject: Re: Performance issue after creating partitions
In-Reply-To: <6F2BE85B-F6D0-4D4C-9DEA-EEE09D97B8EF@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox