Jak filtrować wyniki SQL w relacji ma wiele przejść

101

Zakładając, że mam tabele student, cluboraz student_club:

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

Chcę wiedzieć, jak znaleźć wszystkich uczniów zarówno w klubie piłkarskim (30), jak i baseballowym (50).
Chociaż to zapytanie nie działa, jest to najbliższa rzecz, jaką mam do tej pory:

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
źródło

Odpowiedzi:

146

Byłem ciekawy. A jak wszyscy wiemy, ciekawość ma reputację zabijania kotów.

Jaki jest więc najszybszy sposób oskórowania kota?

Dokładne środowisko skórowania kota dla tego testu:

  • PostgreSQL 9.0 na Debian Squeeze z przyzwoitą pamięcią RAM i ustawieniami.
  • 6.000 studentów, 24.000 członkostwa w klubach (dane skopiowane z podobnej bazy danych z danymi z życia).
  • Nieznaczne odejście od schematu nazewnictwa w pytaniu: student.idjest student.stud_idi club.idjest club.club_id.
  • W tym wątku zapytania nazwałem imieniem ich autora, z indeksem, w którym są dwa.
  • Uruchomiłem wszystkie zapytania kilka razy, aby zapełnić pamięć podręczną, a następnie wybrałem najlepsze z 5 za pomocą EXPLAIN ANALYZE.

  • Odpowiednie wskaźniki (powinny być optymalne - o ile nie wiemy, które kluby będą odpytywane):

    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_pkeynie jest wymagane przez większość zapytań tutaj.
    Klucze podstawowe automatycznie implementują unikalne indeksy w PostgreSQL.
    Ostatni indeks ma nadrobić tę znaną wadę indeksów wielokolumnowych w PostgreSQL:

Wielokolumnowy indeks B-drzewa może być używany z warunkami zapytania, które obejmują dowolny podzbiór kolumn indeksu, ale indeks jest najbardziej wydajny, gdy istnieją ograniczenia na wiodących (skrajnych po lewej) kolumnach.

Wyniki:

Całkowity czas działania z EXPLAIN ANALYZE.

1) Marcin 2: 44,594 ms

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) Erwin 1: 33,217 ms

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) Marcin 1: 31,735 ms

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) Derek: 2,287 ms

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) Erwin 2: 2,181 ms

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) Sean: 2,043 ms

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;

Ostatnie trzy działają prawie tak samo. 4) i 5) skutkują tym samym planem zapytań.

Późne dodatki:

Fantazyjny SQL, ale wydajność nie nadąża.

7) ypercube 1: 148,649 ms

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 ms

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  
      )
   );

Zgodnie z oczekiwaniami, te dwie osoby działają prawie tak samo. Plan zapytania skutkuje skanowaniem tabel, planista nie znajduje tutaj sposobu na użycie indeksów.

9) wildplasser 1: 49,849 ms

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;

Fantazyjny SQL, przyzwoita wydajność jak na CTE. Bardzo egzotyczny plan zapytań.
Ponownie, byłoby interesujące, jak 9.1 radzi sobie z tym. Mam zamiar wkrótce zaktualizować używany tutaj klaster db do wersji 9.1. Może powtórzę cały shebang ...

10) wildplasser 2: 36,986 ms

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);

Wariant CTE zapytania 2). Co zaskakujące, może to spowodować nieco inny plan zapytań z dokładnie tymi samymi danymi. Znalazłem sekwencyjne skanowanie student, w którym wariant podzapytania używał indeksu.

11) ypercube 3: 101,482 ms

Kolejny późny dodatek @ypercube. To naprawdę niesamowite, jak wiele jest sposobów.

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) Erwin 3: 2,377 ms

@ ypercube's 11) jest w rzeczywistości po prostu odwrotnym podejściem do tego prostszego wariantu, którego również brakowało. Działa prawie tak szybko, jak topowe koty.

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) Erwin 4: 2,375 ms

Trudno w to uwierzyć, ale oto kolejny, naprawdę nowy wariant. Widzę potencjał na więcej niż dwa członkostwa, ale jest też jednym z najlepszych kotów z zaledwie dwoma.

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
   )

Dynamiczna liczba członkostwa w klubie

Innymi słowy: różna liczba filtrów. To pytanie dotyczyło dokładnie dwóch członkostwa w klubie. Ale wiele przypadków użycia musi być przygotowanych na różną liczbę.

Szczegółowa dyskusja w tej powiązanej późniejszej odpowiedzi:

Erwin Brandstetter
źródło
1
Brandstetter, Bardzo fajna robota. Rozpocząłem nagrodę za to pytanie, aby dać ci dodatkowy kredyt (ale muszę poczekać 24 godziny). W każdym razie zastanawiam się, jak przebiegają te zapytania, gdy zaczynasz dodawać wiele identyfikatorów club_id zamiast tylko dwóch ...
Xeoncross
@Xeoncross: Wyrazy uznania dla twojego hojnego gestu. :) Przy większej liczbie club_id podejrzewam, że 1) i 2) będą coraz bliżej prędkości, ale musiałaby być większa liczba, aby obalić ranking.
Erwin Brandstetter
jeśli masz więcej niż kilka trefl, stwórz kolejną tabelę zawierającą te trefl. Następnie dołącz do wybranego stołu.
Paul Morgan,
@Erwin: Thnx (dla testów porównawczych). Nie czepianie się, ale być może możesz wypróbować te zapytania (mam na myśli wszystkie, nie tylko moje) z (student_id, club_id)indeksem (lub odwrotnym).
ypercubeᵀᴹ
3
Czy mylę się myśląc, że wszystko poniżej 200 ms jest akceptowalną wydajnością, biorąc pod uwagę przedmiotową domenę i rozmiar próbki? Ze względów osobistych przeprowadziłem własne testy na SQL Server 2008 R2 przy użyciu tych samych indeksów struktury i (jak sądzę) rozproszenia danych, ale skalowania do miliona uczniów (wydaje mi się, że jest to dość duży zestaw dla danej domeny) i nadal nie było Nie ma wiele do rozdzielenia różnych podejść, IMO. Oczywiście te oparte na podziale relacyjnym mogą być ukierunkowane na tabelę bazową, dając im przewagę w postaci „rozszerzalności”.
kiedy
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
Sean
źródło
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)
Derek Kromm
źródło
To zapytanie działa dobrze, ale coś mi przeszkadza w konieczności proszenia RDBMS o sprawdzenie tak wielu indeksów * liczby trefl.
Xeoncross
6
Najbardziej podoba mi się to zapytanie, ponieważ przypomina czysty styl, podobnie jak python w sql. Z radością zamieniłbym 0,44 ms (różnica z zapytaniem Seana) dla tego rodzaju kodu.
MGP
5

Jeśli chcesz tylko student_id, to:

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

Jeśli potrzebujesz również imienia i nazwiska ucznia, to:

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 )

Jeśli masz więcej niż dwa trefl w tabeli club_selection, to:

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 ) )
Paul Morgan
źródło
Pierwsze dwa są zawarte w / to samo co moje zapytanie 1. Ale trzeci dotyczy dodanego pytania @Xeoncross w komentarzach powyżej. Głosowałbym na tę część bez oszustw.
Erwin Brandstetter
Dziękuję za komentarz, ale pokazuję też pewne formatowanie. Zostawię to „tak jak jest”.
Paul Morgan,
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)

Lub bardziej ogólne rozwiązanie, które jest łatwiejsze do rozszerzenia na nkluby i pozwala uniknąć INTERSECT(niedostępne w MySQL) i IN(ponieważ wydajność tego jest do niczego w 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
Martin Smith
źródło
Bez wątpienia druga odpowiedź jest najlepsza w przypadku zapytań generowanych przez kod. Czy na poważnie napiszę 10 złączeń lub podzapytań, aby znaleźć relacyjny podział 10 kryteriów? Heck nie, zamiast tego użyję tego genialnego rozwiązania. Dzięki za nauczenie mnie, co HAVINGrobi MySQL.
Eric L.
4

Kolejny CTE. Wygląda na uporządkowany, ale prawdopodobnie wygeneruje taki sam plan, jak grupowanie w normalnym podzapytaniu.

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)
    ;

Dla tych, którzy chcą przetestować, kopię moich generowanych danych testowych:

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
źródło
Tak, to w efekcie tylko podzapytanie z grupowaniem według, jak w mojej pierwszej wersji. Ten sam plan zapytania + obciążenie CTE daje taką samą wydajność + trochę dla CTE. Niezła konfiguracja testowa.
Erwin Brandstetter
Nie wiem, czy istnieje obciążenie CTE. Dystrybucja danych testowych jest bardzo ważna. Tak samo jest z dostępnością statystyk: po ANALIZIE PRÓŻNIOWEJ czas pracy wzrósł z 67,4 do 1,56 ms. Tylko hash i bitmapy zaangażowane w QP.
wildplasser
To szczególne w twoim przypadku, po usunięciu 80% dużego stołu i wielu aktualizacjach, masz więcej martwych krotek niż cokolwiek innego. Nic dziwnego, analiza próżni bardzo pomaga. Uruchomiłem oba warianty zi bez CTE i, co zaskakujące, plany zapytań nie były identyczne. lub jeszcze lepiej, otworzę w tym celu pokój rozmów.
Erwin Brandstetter
Nie martw się, wiedziałem o 80% martwych awanturach ... Myślę, że statystyki też mają znaczenie. Ale histogram jest raczej „płaski”, biorąc pod uwagę losowe usuwanie. Może to tylko oszacowanie potrzebnych stron, które zmienia się na tyle, że planista zdecyduje się zmienić plany.
wildplasser
3

Więc jest więcej niż jeden sposób na oskórowanie kota .
Dodam jeszcze dwa, żeby było lepiej.

1) Najpierw GRUPA, DOŁĄCZ później

Zakładając, że rozsądny model danych (student_id, club_id)jest unikalny w programie student_club. Druga wersja Martina Smitha jest trochę podobna, ale najpierw dołącza do grup, później. To powinno być szybsze:

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) ISTNIEJE

I oczywiście jest klasyka EXISTS. Podobny do wariantu Dereka z IN. Prosto i szybko. (W MySQL powinno to być trochę szybsze niż wariant z 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);
Erwin Brandstetter
źródło
3

Ponieważ nikt nie dodał tej (klasycznej) wersji:

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  
              )
      )

lub podobne:

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  
              )
      )

Jeszcze jedna próba z nieco innym podejściem. Zainspirowany artykułem w Explain Extended: Multiple atrybuty w tabeli EAV: GROUP BY vs. NOTISTING :

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  
              )
      )

Inne podejście:

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ᵀᴹ
źródło
+1 .. ładne dodatki do niezbyt kompletnej kolekcji kociej skóry! :) Dodałem je do benchmarku.
Erwin Brandstetter
To nie jest uczciwa walka :) Dużą zaletą dzielenia relacyjnego, takiego jak ten, jest to, że dzielnik może być tabelą bazową, więc zmiana dzielnika jest bardzo tania, tj. Kontrast aktualizacji wierszy w tabeli bazowej, na którą jest skierowane to samo zapytanie ze zmianą SQL zapytanie za każdym razem.
onedaywhen
@ErwinBrandstetter: Czy byłoby możliwe dodanie trzeciej odmiany do twoich testów?
ypercubeᵀᴹ
@ypercube: Masz to. Dość pokręcona wersja. :)
Erwin Brandstetter
1
@Erwin: Kiedy uda ci się zmarnować na to trochę czasu, czy możesz również spróbować mieć dwa UNIKALNE Klucze, na obu (stud_id, club_id)i (club_id, stud_id)(lub Podstawowy i Unikatowy)? Nadal uważam, że dla niektórych z tych zapytań różnica od 2 do 140 ms jest zbyt duża, aby można ją było wyjaśnić różnicami w planach wykonania.
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

    ;

Wydaje się, że działa to dość dobrze, ponieważ skanowanie CTE pozwala uniknąć konieczności wykonywania dwóch oddzielnych podzapytań.

Zawsze istnieje powód, aby nadużywać zapytań rekurencyjnych!

(BTW: mysql nie wydaje się mieć zapytań rekurencyjnych)

wildplasser
źródło
+1 za znalezienie kolejnej w połowie przyzwoitej drogi do tego! Dodałem Twoje zapytanie do testu porównawczego. Mam nadzieję, że z tobą wszystko w porządku. :)
Erwin Brandstetter
W porządku. Ale oczywiście miał to być żart. CTE faktycznie działa dobrze, jeśli zostanie dodanych więcej rekordów klubów „bezpańskich” studentów *. (Do testów użyłem 1000 uczniów * 100 klubów i 80%
usunąłem
1

Różne plany zapytań w zapytaniu 2) i 10)

Przetestowałem w prawdziwej bazie danych, więc nazwy różnią się od listy kocich skór. Jest to kopia zapasowa, więc nic się nie zmieniło podczas wszystkich przebiegów testowych (z wyjątkiem drobnych zmian w katalogach).

Zapytanie 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

Zapytanie 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
Erwin Brandstetter
źródło
@wildplasser: Zobacz rozbieżne plany zapytań! Nieoczekiwane dla mnie. strona 9.0. Pokój rozmów był nieporęczny, więc nadużywam tutaj odpowiedzi.
Erwin Brandstetter
Dziwne sceny. Zasadniczo ten sam QP tutaj (9.0.1-beta-coś) dla CTE: skanowanie sekwencyjne + mapa bitowa zamiast skanowania indeksu + scalanie. Może błąd w heurystyce kosztów optymalizatora? Mam zamiar wyprodukować kolejne nadużycie CTE ...
wildplasser,
1

@ erwin-brandstetter Proszę porównać to:

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;

To jak numer 6) autorstwa @sean, chyba po prostu czystszy.

Taai
źródło
2
Musisz wiedzieć, że - @powiadamianie działa tylko w komentarzach, a nie w odpowiedziach. Natknąłem się na ten post przez przypadek. Plan kwerendy i wydajność kwerendy są identyczne jak kwerendy Seana. W rzeczywistości jest to to samo, ale zapytanie Seana z jawną JOINskładnią jest ogólnie preferowaną formą, ponieważ jest jaśniejsze. Jednak +1 za kolejną ważną odpowiedź!
Erwin Brandstetter
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)
    ;

Plan zapytania:

 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)

Więc nadal wydaje się, że chce wykonać skanowanie sekwencyjne na uczniu.

wildplasser
źródło
Nie mogę się doczekać, aby zobaczyć, czy zostało to naprawione w wersji 9.1.
Erwin Brandstetter
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
;

Użycie najszybszego wariantu (Mr. Sean na wykresie Mr. Brandstetter). Może być wariantem z tylko jednym przyłączeniem do macierzy student_club, która ma prawo do życia. Tak więc najdłuższe zapytanie będzie miało tylko dwie kolumny do obliczenia, chodzi o to, aby zapytanie było cienkie.

Stepan Pavlov
źródło
1
Chociaż ten fragment kodu może rozwiązać problem, dołączenie wyjaśnienia naprawdę pomaga poprawić jakość Twojego posta. Pamiętaj, że odpowiadasz na pytanie do czytelników w przyszłości, a nie tylko osoba, która zapyta teraz! Proszę edytować swoje odpowiedzi, aby dodać wyjaśnienie, i dać wskazówkę co zastosować ograniczenia i założenia.
BrokenBinary