Postgres Pro
Downloads
Home   >   mailing lists

Re: Looks like merge join planning time is too big, 55 seconds - Mailing list pgsql-performance

From Sergey Burladyan
Subject Re: Looks like merge join planning time is too big, 55 seconds
Date
Msg-id CAJ2ymdio+ewdT4nmvZtQDsZu7+ZHQeu8vX1kynB-ZPf9J2FMvw@mail.gmail.com
Whole thread Raw
In response to Looks like merge join planning time is too big, 55 seconds  (Sergey Burladyan <eshkinkot@gmail.com>)
List pgsql-performance
Tree view
I find another query with big planning time:
explain select * from xview.user_items_v v where ( v.item_id = 132358330 );
                                                    QUERY PLAN                                                     
-------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.00..363.28 rows=1 width=44)
   Join Filter: (ief.item_id = ix.item_id)
   ->  Index Scan using items_item_ux on items ix  (cost=0.00..359.20 rows=1 width=36)
         Index Cond: (item_id = 132358330)
         Filter: ((xa_txtime IS NULL) AND (user_id > 0) AND (status_id < 20))
   ->  Index Scan using item_enabled_flags_item_id_idx on item_enabled_flags ief  (cost=0.00..4.06 rows=1 width=8)
         Index Cond: (item_id = 132358330)
(7 rows)

Time: 44037.758 ms

looks like planning algorithm hang on 'items' table statistics. Setting enable_mergejoin to off does not help with this query.

--
Sergey Burladyan

pgsql-performance by date:

Previous
From: Sergey Burladyan
Date:
Subject: Re: Looks like merge join planning time is too big, 55 seconds
Next
From: Sergey Burladyan
Date:
Subject: Re: Looks like merge join planning time is too big, 55 seconds