Как я могу “передумать” при чтении плана запросов PostgreSQL?

Я провел более чем час сегодня, озадачивающий сам по плану запросов, который я не мог понять. Запрос был UPDATE и это просто не работало бы вообще. Полностью заведенный в тупик: pg_locks показал, что это ничего не ожидало также. Теперь, я не считаю меня лучшим или худшим читателем плана запросов, но я нахожу этого исключительно трудным. Я задаюсь вопросом, как каждый читает их? Существует ли методология, за которой тузы Pg следуют для точного определения ошибки?

Я планирую задавание другого вопроса относительно того, как работать вокруг этой проблемы, но прямо сейчас я говорю конкретно о том, как считать эти типы планов.

                                         QUERY PLAN                                         
--------------------------------------------------------------------------------------------
 Nested Loop Anti Join  (cost=47680.88..169413.12 rows=1 width=77)
   Join Filter: ((co.fkey_style = v.chrome_styleid) AND (co.name = o.name))
   ->  Nested Loop  (cost=5301.58..31738.10 rows=1 width=81)
         ->  Hash Join  (cost=5301.58..29722.32 rows=229 width=40)
               Hash Cond: ((io.lot_id = iv.lot_id) AND ((io.vin)::text = (iv.vin)::text))
               ->  Seq Scan on options io  (cost=0.00..20223.32 rows=23004 width=36)
                     Filter: (name IS NULL)
               ->  Hash  (cost=4547.33..4547.33 rows=36150 width=24)
                     ->  Seq Scan on vehicles iv  (cost=0.00..4547.33 rows=36150 width=24)
                           Filter: (date_sold IS NULL)
         ->  Index Scan using options_pkey on options co  (cost=0.00..8.79 rows=1 width=49)
               Index Cond: ((co.fkey_style = iv.chrome_styleid) AND (co.code = io.code))
   ->  Hash Join  (cost=42379.30..137424.09 rows=16729 width=26)
         Hash Cond: ((v.lot_id = o.lot_id) AND ((v.vin)::text = (o.vin)::text))
         ->  Seq Scan on vehicles v  (cost=0.00..4547.33 rows=65233 width=24)
         ->  Hash  (cost=20223.32..20223.32 rows=931332 width=44)
               ->  Seq Scan on options o  (cost=0.00..20223.32 rows=931332 width=44)
(17 rows)

Проблема с этим планом запросов - я полагаю, что понимаю - вероятно, лучше всего сказан RhodiumToad (он определенно лучше в этом, таким образом, я буду держать пари на его объяснении, являющемся лучше) irc://irc.freenode.net/#postgresql:

о, тот план потенциально имеет катастрофические последствия, проблема с тем планом состоит в том, что он выполняет чрезвычайно дорогое хэширование для каждой строки, проблемой является оценка rows=1 от другого соединения, и планировщик думает, что нормально помещать чрезвычайно дорогой запрос во внутренний путь nestloop, где внешний путь, как оценивается, возвращает только одну строку. с тех пор, очевидно, оценкой планировщика дорогая часть будет только выполнена однажды, но это имеет очевидную тенденцию действительно испортить на практике проблему, то, что планировщик верит ее собственным оценкам идеально, планировщик должен знать, что различие между "предполагаемым возвращает 1 строку" и "не возможный возвратить больше чем 1 строку", но нисколько не ясно, как включить это в существующий код

Он продолжает:

это может влиять на любое соединение, но обычно присоединяется против подзапросов, наиболее вероятны

Теперь то, когда я прочитал этот план первая вещь, я заметил, было Nested Loop Anti Join, это имело стоимость 169,413 (Я буду придерживаться верхних границ). Это Антисоединение ломается к результату a Nested Loop за счет 31,738, и результат a Hash Join по стоимости 137,424. Теперь, 137,424, намного больше, чем 31,738 таким образом, я знал, что проблемой было Хэширование.

Затем я продолжаю двигаться к EXPLAIN ANALYZE сегмент Hash Join за пределами запроса. Это выполнилось в 7 secs. Я удостоверился, что были индексы на (lot_id, vin), и (co.code, и v.code) - было. Я отключил seq_scan и hashjoin индивидуально и уведомление увеличение скорости меньше чем 2 секунд. Не около достаточно для составления, почему это не прогрессировало после часа.

Но, в конце концов, это я полностью неправ! Да, это была более медленная часть запроса, но потому что rows="1" бит (я предполагаю, что он шел Nested Loop Anti Join). Здесь это - ошибка (отсутствие способности) в планировщике, неверно оценивающем сумму строк? Как я, как предполагается, читаю в это, чтобы прийти к тому же заключению RhodiumToad ?

Это просто rows="1" это, как предполагается, инициировало меня понимающий это?

Я действительно работал VACUUM FULL ANALYZE на всех таблицах, включенных, и это - Postgresql 8.4.