From: | Sergey Burladyan <eshkinkot(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Looks like merge join planning time is too big, 55 seconds |
Date: | 2013-08-01 14:30:39 |
Message-ID: | CAJ2ymdio+ewdT4nmvZtQDsZu7+ZHQeu8vX1kynB-ZPf9J2FMvw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey Burladyan | 2013-08-01 15:17:27 | Re: Looks like merge join planning time is too big, 55 seconds |
Previous Message | Sergey Burladyan | 2013-08-01 11:45:15 | Re: Looks like merge join planning time is too big, 55 seconds |