Re: Looks like merge join planning time is too big, 55 seconds

[Sergey Burladyan <eshkinkot@xxxxxxxxx>]

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