PostgreSQL: существует против левого соединения - PullRequest
4 голосов
/ 24 июня 2010

Я много раз слышал, что postgres обрабатывает существует запросов даже быстрее, чем оставил соединение .http://archives.postgresql.org/pgsql-performance/2002-12/msg00185.php

Это определенно верно для агрегации одной таблицы.

Но в нашем случае существует более одной и той же сборки запроса с , существующей , которая заставляет postgres зависатьнавсегда:

explain 
SELECT count(DISTINCT "groups".id) AS count_all 
FROM "groups"
WHERE (exists(
    select * from products p where groups.id = p.group_id AND exists(
        select * from products_categories pc where p.id = pc.product_id AND pc.category_id in (2,3))) AND groups.id != 3) 

результат:

 Aggregate  (cost=26413436.66..26413436.67 rows=1 width=4)
   ->  Seq Scan on groups  (cost=0.00..26413403.84 rows=13126 width=4)
         Filter: ((id <> 3) AND (subplan))
         SubPlan
           ->  Index Scan using index_products_on_group_id on products p  (cost=0.00..1006.13 rows=1 width=1483)
                 Index Cond: ($1 = group_id)
                 Filter: (subplan)
                 SubPlan
                   ->  Seq Scan on products_categories pc  (cost=0.00..498.49 rows=1 width=8)
                         Filter: ((category_id = ANY ('{2,3}'::integer[])) AND ($0 = product_id))

В чем причина невероятно долгого времени выполнения?Это какая-то проблема конфигурации?

Спасибо, Богдан.

1 Ответ

2 голосов
/ 24 июня 2010

Ну, для каждой строки в "groups" postgresql выполняет полное сканирование products_categories, что не очень хорошо Не обязательно проблема конфигурации, но, возможно, запрос может быть сформулирован без вложенных подзапросов, подобных этому?

SELECT count(DISTINCT "groups".id) AS count_all 
FROM "groups"
WHERE exists(
    select 1 from products p where groups.id = p.group_id
             join products_categories pc on pc.product_id = p.id
    where pc.category_id in (2,3)
    ) and groups.id <> 3

Также у products_categories есть индекс для product_id?

...