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

Поиск
Список
Период
Сортировка
От David Kerr
Тема Re: Looks like merge join planning time is too big, 55 seconds
Дата
Msg-id 20130801175803.GA37145@mr-paradox.net
обсуждение исходный текст
Ответ на Re: Looks like merge join planning time is too big, 55 seconds  (Sergey Burladyan <eshkinkot@gmail.com>)
Список pgsql-performance
On Thu, Aug 01, 2013 at 07:17:27PM +0400, Sergey Burladyan wrote:
- Sergey Burladyan <eshkinkot@gmail.com> writes:
-
- > # explain
- > # select i.item_id, u.user_id from items i
- > # left join users u on u.user_id = i.user_id
- > # where item_id = 169946840;
- > QUERY PLAN
- > ----------------------------------------------------------------------------------------------
- > Nested Loop Left Join (cost=0.00..397.14 rows=1 width=16)
- > -> Index Scan using items_item_ux on items i (cost=0.00..358.84 rows=1 width=16)
- > Index Cond: (item_id = 169946840)
- > -> Index Only Scan using users_user_id_pkey on users u (cost=0.00..38.30 rows=1 width=8)
- > Index Cond: (user_id = i.user_id)
- >
- > time: 55919.910 ms
-
- While running this EXPLAIN backend use disk for a long time:
-  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
                                                                       
- 21638 be/4 postgres    2.10 M/s    9.45 M/s  0.00 % 69.04 % postgres: postgres xxxxx xxx.xxx.xxx.xxx(50987) EXPLAIN
-
- Why it read and write to disk 10 megabytes per second for EXPLAIN query? Cannot understand what is going on here :(


That sounds familiar - is it possible you're running into this?
http://www.postgresql.org/message-id/20120713065122.GA45804@mr-paradox.net


В списке pgsql-performance по дате отправления:

Предыдущее
От: Sergey Burladyan
Дата:
Сообщение: Re: Looks like merge join planning time is too big, 55 seconds
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Performance bug in prepared statement binding in 9.2?