Re: partition table slow planning

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Jatinder Sandhu <jatinder(dot)sandhu(at)flightnetwork(dot)com>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: partition table slow planning
Date: 2019-07-24 05:35:03
Message-ID: CAFiTN-sCF+quVz-jwt60cJFQhyWNuksUEU9cbS_xh4RbhJ4bsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general

On Wed, Jul 24, 2019 at 4:24 AM Jatinder Sandhu
<jatinder(dot)sandhu(at)flightnetwork(dot)com> wrote:
>
>
> We encounter a issue when we do query on partition table directly with proper partition key provide. postgres able to find problem partition but when I do explain plan it showing 95% spend on planning the execution . Here is example
> itinerary=# EXPLAIN ANALYZE SELECT * FROM itinerary WHERE destination ='GRJ' AND departure_date = '2020-01-01' AND month_day = 101
> itinerary-# ;
> QUERY PLAN
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Append (cost=0.29..13.79 rows=11 width=1024) (actual time=0.033..0.037 rows=1 loops=1)
> -> Index Scan using itinerary_101_destination_departure_date_idx on itinerary_101 (cost=0.29..13.73 rows=11 width=1024) (actual time=0.033..0.036 rows=1 loops=1)
> Index Cond: (((destination)::text = 'GRJ'::text) AND ((departure_date)::text = '2020-01-01'::text))
> Filter: (month_day = 101)
> Planning Time: 51.677 ms
> Execution Time: 0.086 ms
>
>
> When I do query on directly on the partition table it is quite fast
> itinerary=# EXPLAIN ANALYZE SELECT * FROM itinerary_101 WHERE destination ='GRJ' AND departure_date = '2020-01-01' AND month_day = 101
> itinerary-# ;
> QUERY PLAN
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
> Index Scan using itinerary_101_destination_departure_date_idx on itinerary_101 (cost=0.29..13.73 rows=11 width=1024) (actual time=0.043..0.048 rows=1 loops=1)
> Index Cond: (((destination)::text = 'GRJ'::text) AND ((departure_date)::text = '2020-01-01'::text))
> Filter: (month_day = 101)
> Planning Time: 0.191 ms
> Execution Time: 0.074 ms
> (5 rows)
>
> itinerary=#
>
> Can we know why this is happening?
>
I guess when you give the query on the parent table, based on your
clause it need to search which partition to scan that can increase the
planning time.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Manuel Rigger 2019-07-24 07:16:32 Attribute has wrong type in ALTER TABLE
Previous Message Michael Paquier 2019-07-24 02:32:16 Re: ANALYZE on parent table results in an error "tuple already updated by self"

Browse pgsql-general by date

  From Date Subject
Next Message jay chauhan 2019-07-24 08:08:30 Re: Request for resolution || Support
Previous Message Ian Barwick 2019-07-24 01:54:44 Re: Default ordering option