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
