Как отфильтровать результаты SQL в отношении "имеет много сквозных"

101

Предполагая , что у меня есть таблицы student, clubи student_club:

student {
    id
    name
}
club {
    id
    name
}
student_club {
    student_id
    club_id
}

Я хочу знать, как найти всех студентов как в футбольном (30), так и в бейсбольном (50) клубах.
Хотя этот запрос не работает, это самое близкое, что у меня есть:

SELECT student.*
FROM   student
INNER  JOIN student_club sc ON student.id = sc.student_id
LEFT   JOIN club c ON c.id = sc.club_id
WHERE  c.id = 30 AND c.id = 50
mysql sql postgresql sql-match-all relational-division Xeoncross
источник

Ответы:

146

Мне было любопытно. И, как все мы знаем, любопытство имеет репутацию убийцы кошек.

Итак, какой самый быстрый способ снять шкуру с кошки?

Точная среда для снятия шкуры кошки для этого теста:

  • PostgreSQL 9.0 на Debian Squeeze с приличной оперативной памятью и настройками.
  • 6.000 студентов, 24000 членских взносов в клубы (данные скопированы из аналогичной базы данных с данными из реальной жизни).
  • Небольшое отклонение от схемы именования в вопросе: student.idесть student.stud_idи club.idесть club.club_idздесь.
  • Я назвал запросы в честь их автора в этой ветке с индексом, где их два.
  • Я выполнил все запросы пару раз, чтобы заполнить кеш, затем выбрал лучшие из 5 с помощью EXPLAIN ANALYZE.

  • Соответствующие индексы (должны быть оптимальными - до тех пор, пока мы не знаем, какие клубы будут опрошены):

    ALTER TABLE student ADD CONSTRAINT student_pkey PRIMARY KEY(stud_id );
ALTER TABLE student_club ADD CONSTRAINT sc_pkey PRIMARY KEY(stud_id, club_id);
ALTER TABLE club       ADD CONSTRAINT club_pkey PRIMARY KEY(club_id );
CREATE INDEX sc_club_id_idx ON student_club (club_id);

    club_pkeyздесь не требуется для большинства запросов.
    Первичные ключи автоматически реализуют уникальные индексы в PostgreSQL.
    Последний индекс призван восполнить этот известный недостаток многостолбцовых индексов в PostgreSQL:

Многоколоночный индекс в виде B-дерева можно использовать с условиями запроса, которые включают любое подмножество столбцов индекса, но индекс наиболее эффективен, когда есть ограничения на ведущие (крайние левые) столбцы.

Полученные результаты:

Общее время выполнения из EXPLAIN ANALYZE.

1) Мартин 2: 44,594 мс

SELECT s.stud_id, s.name
FROM   student s
JOIN   student_club sc USING (stud_id)
WHERE  sc.club_id IN (30, 50)
GROUP  BY 1,2
HAVING COUNT(*) > 1;

2) Эрвин 1: 33,217 мс

SELECT s.stud_id, s.name
FROM   student s
JOIN   (
   SELECT stud_id
   FROM   student_club
   WHERE  club_id IN (30, 50)
   GROUP  BY 1
   HAVING COUNT(*) > 1
   ) sc USING (stud_id);

3) Мартин 1: 31,735 мс

SELECT s.stud_id, s.name
   FROM   student s
   WHERE  student_id IN (
   SELECT student_id
   FROM   student_club
   WHERE  club_id = 30
   INTERSECT
   SELECT stud_id
   FROM   student_club
   WHERE  club_id = 50);

4) Дерек: 2,287 мс

SELECT s.stud_id,  s.name
FROM   student s
WHERE  s.stud_id IN (SELECT stud_id FROM student_club WHERE club_id = 30)
AND    s.stud_id IN (SELECT stud_id FROM student_club WHERE club_id = 50);

5) Эрвин 2: 2,181 мс

SELECT s.stud_id,  s.name
FROM   student s
WHERE  EXISTS (SELECT * FROM student_club
               WHERE  stud_id = s.stud_id AND club_id = 30)
AND    EXISTS (SELECT * FROM student_club
               WHERE  stud_id = s.stud_id AND club_id = 50);

6) Шон: 2,043 мс

SELECT s.stud_id, s.name
FROM   student s
JOIN   student_club x ON s.stud_id = x.stud_id
JOIN   student_club y ON s.stud_id = y.stud_id
WHERE  x.club_id = 30
AND    y.club_id = 50;

Последние три работают примерно так же. 4) и 5) приводят к одному и тому же плану запроса.

Поздние дополнения:

Замечательный SQL, но производительность не успевает.

7) ypercube 1: 148,649 мс

SELECT s.stud_id,  s.name
FROM   student AS s
WHERE  NOT EXISTS (
   SELECT *
   FROM   club AS c 
   WHERE  c.club_id IN (30, 50)
   AND    NOT EXISTS (
      SELECT *
      FROM   student_club AS sc 
      WHERE  sc.stud_id = s.stud_id
      AND    sc.club_id = c.club_id  
      )
   );

8) ypercube 2: 147,497 мс

SELECT s.stud_id,  s.name
FROM   student AS s
WHERE  NOT EXISTS (
   SELECT *
   FROM  (
      SELECT 30 AS club_id  
      UNION  ALL
      SELECT 50
      ) AS c
   WHERE NOT EXISTS (
      SELECT *
      FROM   student_club AS sc 
      WHERE  sc.stud_id = s.stud_id
      AND    sc.club_id = c.club_id  
      )
   );

Как и ожидалось, эти двое работают практически одинаково. Результатом плана запроса является сканирование таблиц, планировщик не находит здесь способа использовать индексы.

9) wildplasser 1: 49,849 мс

WITH RECURSIVE two AS (
   SELECT 1::int AS level
        , stud_id
   FROM   student_club sc1
   WHERE  sc1.club_id = 30
   UNION
   SELECT two.level + 1 AS level
        , sc2.stud_id
   FROM   student_club sc2
   JOIN   two USING (stud_id)
   WHERE  sc2.club_id = 50
   AND    two.level = 1
   )
SELECT s.stud_id, s.student
FROM   student s
JOIN   two USING (studid)
WHERE  two.level > 1;

Необычный SQL, достойная производительность для CTE. Очень экзотический план запроса.
Опять же, было бы интересно, как 9.1 справляется с этим. Вскоре я собираюсь обновить используемый здесь кластер db до 9.1. Может, перепрошу весь шебанг ...

10) wildplasser 2: 36,986 мс

WITH sc AS (
   SELECT stud_id
   FROM   student_club
   WHERE  club_id IN (30,50)
   GROUP  BY stud_id
   HAVING COUNT(*) > 1
   )
SELECT s.*
FROM   student s
JOIN   sc USING (stud_id);

CTE вариант запроса 2). Удивительно, но это может привести к немного другому плану запроса с точно такими же данными. Я нашел последовательное сканирование student, где вариант подзапроса использовал индекс.

11) ypercube 3: 101,482 мс

Еще одно позднее добавление @ypercube. Просто поразительно, сколько существует способов.

SELECT s.stud_id, s.student
FROM   student s
JOIN   student_club sc USING (stud_id)
WHERE  sc.club_id = 10                 -- member in 1st club ...
AND    NOT EXISTS (
   SELECT *
   FROM  (SELECT 14 AS club_id) AS c  -- can't be excluded for missing the 2nd
   WHERE  NOT EXISTS (
      SELECT *
      FROM   student_club AS d
      WHERE  d.stud_id = sc.stud_id
      AND    d.club_id = c.club_id
      )
   )

12) Эрвин 3: 2,377 мс

@ypercube 11) на самом деле представляет собой просто запутанный обратный подход этого более простого варианта, которого также все еще не было. Работает почти так же быстро, как и лучшие кошки.

SELECT s.*
FROM   student s
JOIN   student_club x USING (stud_id)
WHERE  sc.club_id = 10                 -- member in 1st club ...
AND    EXISTS (                        -- ... and membership in 2nd exists
   SELECT *
   FROM   student_club AS y
   WHERE  y.stud_id = s.stud_id
   AND    y.club_id = 14
   )

13) Эрвин 4: 2,375 мс

Трудно поверить, но вот еще один, действительно новый вариант. Я вижу потенциал для более чем двух членств, но он также входит в число лучших кошек, имея всего два.

SELECT s.*
FROM   student AS s
WHERE  EXISTS (
   SELECT *
   FROM   student_club AS x
   JOIN   student_club AS y USING (stud_id)
   WHERE  x.stud_id = s.stud_id
   AND    x.club_id = 14
   AND    y.club_id = 10
   )

Динамическое количество членств в клубах

Другими словами: разное количество фильтров. В этом вопросе задано ровно два членства в клубах. Но многие варианты использования должны быть готовы к разному количеству.

Подробное обсуждение в этом более позднем ответе:

Эрвин Брандштеттер
источник
1
Brandstetter, Очень хорошая работа. Я назначил награду за этот вопрос, чтобы дать вам дополнительную оценку (но мне нужно ждать 24 часа). В любом случае, мне интересно, как проходят эти запросы, когда вы начинаете добавлять несколько club_id вместо двух ...
Xeoncross
@Xeoncross: Спасибо за ваш щедрый жест. :) С большим количеством club_ids я подозреваю, что 1) и 2) станут ближе по скорости, но это должно быть большее число, чтобы опустить рейтинг.
Эрвин Брандштеттер
если у вас больше пары клубов, создайте другую таблицу, содержащую эти клубы. Затем присоединяйтесь к этой таблице по вашему выбору.
Пол Морган
@Erwin: Спасибо (за тесты). Не придираюсь, но, возможно, вы можете попробовать эти запросы (я имею в виду все, а не только мои) с (student_id, club_id)(или наоборот) индексом.
ypercubeᵀᴹ
3
Я ошибаюсь, полагая, что все, что меньше 200 мс, является приемлемой производительностью, учитывая рассматриваемую область и размер выборки? Для личного интереса я провел свои собственные тесты на SQL Server 2008 R2, используя те же структурные индексы и (я думаю) разброс данных, но с масштабированием до миллиона студентов (я считаю, что достаточно большой набор для данного домена), и все еще не было Сложно разделить разные подходы, ИМО. Конечно, те, которые основаны на реляционном делении, могут быть нацелены на базовую таблицу, что дает им преимущество «расширяемости».
однажды, когда
18 
SELECT s.*
FROM student s
INNER JOIN student_club sc_soccer ON s.id = sc_soccer.student_id
INNER JOIN student_club sc_baseball ON s.id = sc_baseball.student_id
WHERE 
 sc_baseball.club_id = 50 AND 
 sc_soccer.club_id = 30
Шон
источник
10 
select *
from student
where id in (select student_id from student_club where club_id = 30)
and id in (select student_id from student_club where club_id = 50)
Дерек Кромм
источник
Этот запрос работает нормально, но что-то меня беспокоит, что мне приходится просить СУБД проверять столько индексов * количество клубов.
Xeoncross
6
Мне больше всего нравится этот запрос, потому что он похож на чистый стиль, как python в sql. Я бы с радостью променял 0,44 мс (разница с запросом Шона) на такой код.
MGP
5

Если вам просто нужен student_id, тогда:

    Select student_id
      from student_club
     where club_id in ( 30, 50 )
  group by student_id
    having count( student_id ) = 2

Если вам также нужно имя студента, то:

Select student_id, name
  from student s
 where exists( select *
                 from student_club sc
                where s.student_id = sc.student_id
                  and club_id in ( 30, 50 )
             group by sc.student_id
               having count( sc.student_id ) = 2 )

Если у вас более двух клубов в таблице club_selection, тогда:

Select student_id, name
  from student s
 where exists( select *
                 from student_club sc
                where s.student_id = sc.student_id
                  and exists( select * 
                                from club_selection cs
                               where sc.club_id = cs.club_id )
             group by sc.student_id
               having count( sc.student_id ) = ( select count( * )
                                                   from club_selection ) )
Пол Морган
источник
Первые два включены в / такие же, как мой запрос 1. Но третий касается вопроса, добавленного @Xeoncross в комментариях выше. Я бы проголосовал за эту часть без дураков.
Эрвин Брандштеттер,
Спасибо за комментарий, но я также демонстрирую форматирование. Я оставлю все как есть.
Пол Морган
4 
SELECT *
FROM   student
WHERE  id IN (SELECT student_id
              FROM   student_club
              WHERE  club_id = 30
              INTERSECT
              SELECT student_id
              FROM   student_club
              WHERE  club_id = 50)

Или более общее решение, которое легче распространить на nклубы и которое позволяет избежать INTERSECT(недоступно в MySQL) и IN(поскольку производительность этого отстойная в MySQL )

SELECT s.id,
       s.name
FROM   student s
       join student_club sc
         ON s.id = sc.student_id
WHERE  sc.club_id IN ( 30, 50 )
GROUP  BY s.id,
          s.name
HAVING COUNT(DISTINCT sc.club_id) = 2
Мартин Смит
источник
Без сомнения, ваш второй ответ лучше всего подходит для запросов, которые генерируются кодом. Собираюсь ли я серьезно написать 10 объединений или подзапросов, чтобы найти реляционное разделение 10 критериев? Черт возьми, я воспользуюсь этим гениальным решением. Спасибо, что научили меня тому, что HAVINGделает в MySQL.
Эрик Л.
4

Еще один CTE. Он выглядит чистым, но, вероятно, сгенерирует тот же план, что и groupby в обычном подзапросе.

WITH two AS (
    SELECT student_id FROM tmp.student_club
    WHERE club_id IN (30,50)
    GROUP BY student_id
    HAVING COUNT(*) > 1
    )
SELECT st.* FROM tmp.student st
JOIN two ON (two.student_id=st.id)
    ;

Для тех, кто хочет протестировать, копия моей генерации тестовых данных:

DROP SCHEMA tmp CASCADE;
CREATE SCHEMA tmp;

CREATE TABLE tmp.student
    ( id INTEGER NOT NULL PRIMARY KEY
    , sname VARCHAR
    );

CREATE TABLE tmp.club
    ( id INTEGER NOT NULL PRIMARY KEY
    , cname VARCHAR
    );

CREATE TABLE tmp.student_club
    ( student_id INTEGER NOT NULL  REFERENCES tmp.student(id)
    , club_id INTEGER NOT NULL  REFERENCES tmp.club(id)
    );

INSERT INTO tmp.student(id)
    SELECT generate_series(1,1000)
    ;

INSERT INTO tmp.club(id)
    SELECT generate_series(1,100)
    ;

INSERT INTO tmp.student_club(student_id,club_id)
    SELECT st.id  , cl.id
    FROM tmp.student st, tmp.club cl
    ;

DELETE FROM tmp.student_club
WHERE random() < 0.8
    ;

UPDATE tmp.student SET sname = 'Student#' || id::text ;
UPDATE tmp.club SET cname = 'Soccer' WHERE id = 30;
UPDATE tmp.club SET cname = 'Baseball' WHERE id = 50;

ALTER TABLE tmp.student_club
    ADD PRIMARY KEY (student_id,club_id)
    ;
Wildplasser
источник
Да, это просто подзапрос с group by, как в моей первой версии. Тот же план запроса + накладные расходы CTE приводят к той же производительности + немного для CTE. Тем не менее, хорошая тестовая установка.
Эрвин Брандштеттер,
Я не знаю, есть ли CTE-накладные расходы. Распространение тестовых данных очень важно. Так же как и доступность статистики: после ВАКУУМНОГО АНАЛИЗА время работы увеличилось с 67,4 до 1,56 мс. В QP задействованы только хеш и растровые изображения.
wildplasser
Это особенное в вашем случае, после удаления 80% большой таблицы и большого обновления у вас было больше мертвых кортежей, чем что-либо еще. Неудивительно, что вакуумный анализ очень помогает. Я запускал оба варианта с CTE и без него, и, что удивительно, планы запросов не были идентичными. или еще лучше, я открою для этого чат.
Эрвин Брандштеттер,
Не волнуйтесь, я знал о 80% мертвых строк ... Думаю, статистика тоже имеет значение. Но гистограмма довольно плоская, учитывая случайное удаление. Возможно, это просто оценка количества необходимых страниц, которая изменится достаточно, чтобы планировщик решил сменить план.
wildplasser
3

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

1) Сначала ГРУППА, позже ПРИСОЕДИНЯЙТЕСЬ

Предполагая вменяемый модель данных , где (student_id, club_id)находится уникальный в student_club. Вторая версия Мартина Смита чем-то похожа, но он присоединяется к первым, а потом к группам. Это должно быть быстрее:

SELECT s.id, s.name
  FROM student s
  JOIN (
   SELECT student_id
     FROM student_club
    WHERE club_id IN (30, 50)
    GROUP BY 1
   HAVING COUNT(*) > 1
       ) sc USING (student_id);

2) СУЩЕСТВУЕТ

И, конечно же, классика EXISTS. Подобно варианту Дерека с IN. Просто и быстро. (В MySQL это должно быть немного быстрее, чем вариант с IN):

SELECT s.id, s.name
  FROM student s
 WHERE EXISTS (SELECT 1 FROM student_club
               WHERE  student_id = s.student_id AND club_id = 30)
   AND EXISTS (SELECT 1 FROM student_club
               WHERE  student_id = s.student_id AND club_id = 50);
Эрвин Брандштеттер
источник
3

Поскольку эту (классическую) версию никто не добавил:

SELECT s.*
FROM student AS s
WHERE NOT EXISTS
      ( SELECT *
        FROM club AS c 
        WHERE c.id IN (30, 50)
          AND NOT EXISTS
              ( SELECT *
                FROM student_club AS sc 
                WHERE sc.student_id = s.id
                  AND sc.club_id = c.id  
              )
      )

или похожие:

SELECT s.*
FROM student AS s
WHERE NOT EXISTS
      ( SELECT *
        FROM
          ( SELECT 30 AS club_id  
          UNION ALL
            SELECT 50
          ) AS c
        WHERE NOT EXISTS
              ( SELECT *
                FROM student_club AS sc 
                WHERE sc.student_id = s.id
                  AND sc.club_id = c.club_id  
              )
      )

Еще одна попытка с немного другим подходом. На основе статьи в Explain Extended: несколько атрибутов в таблице EAV: GROUP BY vs. NOT EXISTS :

SELECT s.*
FROM student_club AS sc
  JOIN student AS s
    ON s.student_id = sc.student_id
WHERE sc.club_id = 50                      --- one option here
  AND NOT EXISTS
      ( SELECT *
        FROM
          ( SELECT 30 AS club_id           --- all the rest in here
                                           --- as in previous query
          ) AS c
        WHERE NOT EXISTS
              ( SELECT *
                FROM student_club AS scc 
                WHERE scc.student_id = sc.id
                  AND scc.club_id = c.club_id  
              )
      )

Другой подход:

SELECT s.stud_id
FROM   student s

EXCEPT

SELECT stud_id
FROM 
  ( SELECT s.stud_id, c.club_id
    FROM student s 
      CROSS JOIN (VALUES (30),(50)) c (club_id)
  EXCEPT
    SELECT stud_id, club_id
    FROM student_club
    WHERE club_id IN (30, 50)   -- optional. Not needed but may affect performance
  ) x ;
ypercubeᵀᴹ
источник
+1 .. приятные дополнения к не самой полной коллекции кошачьих шкур! :) Я добавил их в тест.
Эрвин Брандштеттер
Это нечестная борьба :) Большим преимуществом реляционного деления, такого как этот, является то, что делитель может быть базовой таблицей, так что изменение делителя обходится очень дешево, т.е. строки обновления контраста в базовой таблице, нацеленной на тот же запрос с изменением SQL запрашивать каждый раз.
однажды, когда
@ErwinBrandstetter: Можно ли добавить в ваши тесты третий вариант?
ypercubeᵀᴹ
@ypercube: Вы поняли. Довольно закрученная версия. :)
Эрвин Брандштеттер
1
@Erwin: Если вам удастся потратить на это время, можете ли вы также попробовать иметь два УНИКАЛЬНЫХ ключа на обоих (stud_id, club_id)и (club_id, stud_id)(или Первичном и Уникальном)? Я все еще думаю, что для некоторых из этих запросов разница от 2 до 140 мс слишком велика, чтобы ее можно было объяснить различиями в планах выполнения.
ypercubeᵀᴹ
2 
WITH RECURSIVE two AS
    ( SELECT 1::integer AS level
    , student_id
    FROM tmp.student_club sc0
    WHERE sc0.club_id = 30
    UNION
    SELECT 1+two.level AS level
    , sc1.student_id
    FROM tmp.student_club sc1
    JOIN two ON (two.student_id = sc1.student_id)
    WHERE sc1.club_id = 50
    AND two.level=1
    )
SELECT st.* FROM tmp.student st
JOIN two ON (two.student_id=st.id)
WHERE two.level> 1

    ;

Кажется, это работает достаточно хорошо, так как CTE-сканирование позволяет избежать необходимости в двух отдельных подзапросах.

Всегда есть причина злоупотреблять рекурсивными запросами!

(Кстати: в mysql нет рекурсивных запросов)

Wildplasser
источник
+1 за то, что нашел еще один достойный путь к этому! Я добавил ваш запрос в тест. Надеюсь, с тобой все в порядке. :)
Эрвин Брандштеттер
Все нормально. Но, конечно, это было задумано как шутка. CTE действительно хорошо работает, если добавлено больше записей клуба «заблудших» студентов *. (Для тестирования я использовал 1000 студентов * 100 клубов и случайно удалил 80%)
wildplasser
1

Различные планы запроса в запросе 2) и 10)

Я тестировал db в реальной жизни, поэтому имена отличаются от списка кошачьих шкур. Это резервная копия, поэтому во время всех тестовых запусков ничего не менялось (кроме незначительных изменений в каталогах).

Запрос 2)

SELECT a.*
FROM   ef.adr a
JOIN (
    SELECT adr_id
    FROM   ef.adratt
    WHERE  att_id IN (10,14)
    GROUP  BY adr_id
    HAVING COUNT(*) > 1) t using (adr_id);

Merge Join  (cost=630.10..1248.78 rows=627 width=295) (actual time=13.025..34.726 rows=67 loops=1)
  Merge Cond: (a.adr_id = adratt.adr_id)
  ->  Index Scan using adr_pkey on adr a  (cost=0.00..523.39 rows=5767 width=295) (actual time=0.023..11.308 rows=5356 loops=1)
  ->  Sort  (cost=630.10..636.37 rows=627 width=4) (actual time=12.891..13.004 rows=67 loops=1)
        Sort Key: adratt.adr_id
        Sort Method:  quicksort  Memory: 28kB
        ->  HashAggregate  (cost=450.87..488.49 rows=627 width=4) (actual time=12.386..12.710 rows=67 loops=1)
              Filter: (count(*) > 1)
              ->  Bitmap Heap Scan on adratt  (cost=97.66..394.81 rows=2803 width=4) (actual time=0.245..5.958 rows=2811 loops=1)
                    Recheck Cond: (att_id = ANY ('{10,14}'::integer[]))
                    ->  Bitmap Index Scan on adratt_att_id_idx  (cost=0.00..94.86 rows=2803 width=0) (actual time=0.217..0.217 rows=2811 loops=1)
                          Index Cond: (att_id = ANY ('{10,14}'::integer[]))
Total runtime: 34.928 ms

Запрос 10)

WITH two AS (
    SELECT adr_id
    FROM   ef.adratt
    WHERE  att_id IN (10,14)
    GROUP  BY adr_id
    HAVING COUNT(*) > 1
    )
SELECT a.*
FROM   ef.adr a
JOIN   two using (adr_id);

Hash Join  (cost=1161.52..1261.84 rows=627 width=295) (actual time=36.188..37.269 rows=67 loops=1)
  Hash Cond: (two.adr_id = a.adr_id)
  CTE two
    ->  HashAggregate  (cost=450.87..488.49 rows=627 width=4) (actual time=13.059..13.447 rows=67 loops=1)
          Filter: (count(*) > 1)
          ->  Bitmap Heap Scan on adratt  (cost=97.66..394.81 rows=2803 width=4) (actual time=0.252..6.252 rows=2811 loops=1)
                Recheck Cond: (att_id = ANY ('{10,14}'::integer[]))
                ->  Bitmap Index Scan on adratt_att_id_idx  (cost=0.00..94.86 rows=2803 width=0) (actual time=0.226..0.226 rows=2811 loops=1)
                      Index Cond: (att_id = ANY ('{10,14}'::integer[]))
  ->  CTE Scan on two  (cost=0.00..50.16 rows=627 width=4) (actual time=13.065..13.677 rows=67 loops=1)
  ->  Hash  (cost=384.68..384.68 rows=5767 width=295) (actual time=23.097..23.097 rows=5767 loops=1)
        Buckets: 1024  Batches: 1  Memory Usage: 1153kB
        ->  Seq Scan on adr a  (cost=0.00..384.68 rows=5767 width=295) (actual time=0.005..10.955 rows=5767 loops=1)
Total runtime: 37.482 ms
Эрвин Брандштеттер
источник
@wildplasser: Смотрите разные планы запросов! Неожиданно для меня. стр. 9.0. Чат был громоздким, поэтому я злоупотребляю ответом здесь.
Эрвин Брандштеттер,
Странные сцены. В основном тот же QP (9.0.1-beta-something) для CTE: seq scan + bitmap вместо index scan + merge. Может быть, ошибка в эвристике оптимизатора? Я собираюсь произвести еще одно оскорбление CTE ...
wildplasser
1

@ erwin-brandstetter Пожалуйста, сравните это:

SELECT s.stud_id, s.name
FROM   student s, student_club x, student_club y
WHERE  x.club_id = 30
AND    s.stud_id = x.stud_id
AND    y.club_id = 50
AND    s.stud_id = y.stud_id;

Это как номер 6 от @sean, просто чище, я думаю.

Таай
источник
2
Вы должны знать, что @уведомление работает только в комментариях, но не в ответах. Я случайно наткнулся на этот пост. План запроса и производительность вашего запроса идентичны запросу Шона. Это фактически то же самое, но запрос Шона с явным JOINсинтаксисом является обычно предпочтительной формой, потому что это понятнее. +1 за еще один верный ответ!
Эрвин Брандштеттер,
0 
-- EXPLAIN ANALYZE
WITH two AS (
    SELECT c0.student_id
    FROM tmp.student_club c0
    , tmp.student_club c1
    WHERE c0.student_id = c1.student_id
    AND c0.club_id = 30
    AND c1.club_id = 50
    )
SELECT st.* FROM tmp.student st
JOIN two ON (two.student_id=st.id)
    ;

План запроса:

 Hash Join  (cost=1904.76..1919.09 rows=337 width=15) (actual time=6.937..8.771 rows=324 loops=1)
   Hash Cond: (two.student_id = st.id)
   CTE two
     ->  Hash Join  (cost=849.97..1645.76 rows=337 width=4) (actual time=4.932..6.488 rows=324 loops=1)
           Hash Cond: (c1.student_id = c0.student_id)
           ->  Bitmap Heap Scan on student_club c1  (cost=32.76..796.94 rows=1614 width=4) (actual time=0.667..1.835 rows=1646 loops=1)
                 Recheck Cond: (club_id = 50)
                 ->  Bitmap Index Scan on sc_club_id_idx  (cost=0.00..32.36 rows=1614 width=0) (actual time=0.473..0.473 rows=1646 loops=1)                     
                       Index Cond: (club_id = 50)
           ->  Hash  (cost=797.00..797.00 rows=1617 width=4) (actual time=4.203..4.203 rows=1620 loops=1)
                 Buckets: 1024  Batches: 1  Memory Usage: 57kB
                 ->  Bitmap Heap Scan on student_club c0  (cost=32.79..797.00 rows=1617 width=4) (actual time=0.663..3.596 rows=1620 loops=1)                   
                       Recheck Cond: (club_id = 30)
                       ->  Bitmap Index Scan on sc_club_id_idx  (cost=0.00..32.38 rows=1617 width=0) (actual time=0.469..0.469 rows=1620 loops=1)
                             Index Cond: (club_id = 30)
   ->  CTE Scan on two  (cost=0.00..6.74 rows=337 width=4) (actual time=4.935..6.591 rows=324 loops=1)
   ->  Hash  (cost=159.00..159.00 rows=8000 width=15) (actual time=1.979..1.979 rows=8000 loops=1)
         Buckets: 1024  Batches: 1  Memory Usage: 374kB
         ->  Seq Scan on student st  (cost=0.00..159.00 rows=8000 width=15) (actual time=0.093..0.759 rows=8000 loops=1)
 Total runtime: 8.989 ms
(20 rows)

Так что, похоже, он все еще хочет сканировать seq для ученика.

Wildplasser
источник
Не могу дождаться, чтобы увидеть, было ли это исправлено в 9.1.
Эрвин Брандштеттер,
0 
SELECT s.stud_id, s.name
FROM   student s,
(
select x.stud_id from 
student_club x 
JOIN   student_club y ON x.stud_id = y.stud_id
WHERE  x.club_id = 30
AND    y.club_id = 50
) tmp_tbl
where tmp_tbl.stud_id = s.stud_id
;

Использование самого быстрого варианта (мистер Шон в диаграмме мистера Брандштеттера). Может быть вариант только с одним присоединением только к матрице student_club, имеющей право на жизнь. Таким образом, самый длинный запрос будет иметь только два столбца для вычисления, идея состоит в том, чтобы сделать запрос тонким.

Степан Павлов
источник
1
Хотя этот фрагмент кода может решить вопрос, включение объяснения действительно помогает улучшить качество вашего сообщения. Помните, что вы отвечаете на вопрос для будущих читателей, а не только для человека, который задает его сейчас! Пожалуйста , измените свой ответ , чтобы добавить объяснение, и дать указание о том , что применять ограничения и допущения.
BrokenBinary