Das Filtern von SQL führt zu einer Beziehung mit vielen Durchgängen

100

Unter der Annahme , ich die Tabellen haben student, clubund student_club:

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

Ich möchte wissen, wie man alle Schüler sowohl im Fußball- (30) als auch im Baseballclub (50) findet.
Diese Abfrage funktioniert zwar nicht, ist aber die nächste, die ich bisher habe:

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
Xeoncross
quelle

Antworten:

145

Ich war neugierig. Und wie wir alle wissen, hat Neugier den Ruf, Katzen zu töten.

Also, was ist der schnellste Weg, eine Katze zu häuten?

Die genaue Umgebung für das Häuten von Katzen für diesen Test:

  • PostgreSQL 9.0 auf Debian Squeeze mit anständigem RAM und Einstellungen.
  • 6.000 Studenten, 24.000 Clubmitgliedschaften (Daten aus einer ähnlichen Datenbank mit realen Daten kopiert.)
  • Leichte Ablenkung vom Namensschema in der Frage: student.idist student.stud_idund club.idist club.club_idhier.
  • Ich habe die Abfragen in diesem Thread nach ihrem Autor benannt, mit einem Index, in dem es zwei gibt.
  • Ich habe alle Abfragen ein paar Mal ausgeführt, um den Cache zu füllen, und dann mit EXPLAIN ANALYZE das Beste aus 5 ausgewählt.
  • Relevante Indizes (sollten das Optimum sein - solange wir nicht wissen, welche Clubs abgefragt werden):

    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_pkeywird von den meisten Abfragen hier nicht benötigt.
    Primärschlüssel implementieren eindeutige Indizes automatisch in PostgreSQL.
    Der letzte Index soll diesen bekannten Mangel an mehrspaltigen Indizes unter PostgreSQL ausgleichen:

Ein mehrspaltiger B-Baum-Index kann mit Abfragebedingungen verwendet werden, die eine beliebige Teilmenge der Indexspalten betreffen. Der Index ist jedoch am effizientesten, wenn Einschränkungen für die führenden Spalten (ganz links) bestehen.

Ergebnisse:

Gesamtlaufzeiten von EXPLAIN ANALYZE.

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

Die letzten drei sind ziemlich gleich. 4) und 5) führen zu demselben Abfrageplan.

Späte Ergänzungen:

Ausgefallene SQL, aber die Leistung kann nicht mithalten.

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

Wie erwartet arbeiten diese beiden fast gleich. Der Abfrageplan führt zu Tabellenscans. Der Planer findet hier keine Möglichkeit, die Indizes zu verwenden.


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;

Ausgefallene SQL, anständige Leistung für einen CTE. Sehr exotischer Abfrageplan.
Auch hier wäre interessant, wie 9.1 damit umgeht. Ich werde den hier verwendeten Datenbankcluster bald auf 9.1 aktualisieren. Vielleicht werde ich den ganzen Schebang wiederholen ...


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

CTE-Variante von Abfrage 2). Überraschenderweise kann dies zu einem etwas anderen Abfrageplan mit genau denselben Daten führen. Ich fand einen sequentiellen Scan an student, bei dem die Unterabfrage-Variante den Index verwendete.


11) Ypercube 3: 101,482 ms

Ein weiterer später Zusatz @ypercube. Es ist wirklich erstaunlich, wie viele Möglichkeiten es gibt.

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

@ ypercubes 11) ist eigentlich nur der umwerfende umgekehrte Ansatz dieser einfacheren Variante, der auch noch fehlte. Leistung fast so schnell wie die Top-Katzen.

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

Kaum zu glauben, aber hier ist eine andere, wirklich neue Variante. Ich sehe Potenzial für mehr als zwei Mitgliedschaften, aber es zählt auch zu den Top-Katzen mit nur zwei.

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
   )

Dynamische Anzahl von Clubmitgliedschaften

Mit anderen Worten: unterschiedliche Anzahl von Filtern. Diese Frage stellte genau zwei Clubmitgliedschaften. Viele Anwendungsfälle müssen sich jedoch auf eine unterschiedliche Anzahl vorbereiten.

Detaillierte Diskussion in dieser verwandten späteren Antwort:

Erwin Brandstetter
quelle
1
Brandstetter, sehr gute Arbeit. Ich habe eine Prämie für diese Frage gestartet, um Ihnen zusätzliche Anerkennung zu geben (aber ich muss 24 Stunden warten). Wie auch immer, ich frage mich, wie diese Abfragen verlaufen, wenn Sie anfangen, mehrere club_id's anstelle von nur zwei
hinzuzufügen
@Xeoncross: Ein großes Lob an Ihre großzügige Geste. :) Mit mehr club_ids vermute ich, dass 1) und 2) schneller werden, aber es müsste eine größere Zahl sein, um die Rangliste zu stürzen.
Erwin Brandstetter
Wenn Sie mehr als ein paar Clubs haben, erstellen Sie eine weitere Tabelle, die diese Clubs enthält. Verbinden Sie sich dann mit dieser Tabelle in Ihrer Auswahl.
Paul Morgan
@Erwin: Danke (für die Benchmarks). Kein Nitpicking, aber vielleicht können Sie diese Abfragen (ich meine alle, nicht nur meine) mit einem (student_id, club_id)(oder dem umgekehrten) Index versuchen .
Ypercubeᵀᴹ
3
Bin ich falsch, wenn ich denke, dass alles unter 200 ms angesichts der fraglichen Domäne und der Stichprobengröße eine akzeptable Leistung ist? Aus persönlichem Interesse habe ich meine eigenen Tests mit SQL Server 2008 R2 unter Verwendung der gleichen Strukturindizes und (glaube ich) der Datenverteilung durchgeführt, aber auf eine Million Studenten skaliert (meiner Meinung nach eine relativ große Menge für die gegebene Domäne), und es gab immer noch keine Es ist nicht viel, um die verschiedenen Ansätze zu trennen, IMO. Natürlich könnten diejenigen, die auf relationaler Teilung basieren, auf eine Basistabelle abzielen, was ihnen den Vorteil der "Erweiterbarkeit" verschafft.
Tag, wenn
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
quelle
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
quelle
Diese Abfrage funktioniert gut, aber etwas stört mich daran, dass ich das RDBMS bitten muss, so viele Indizes * der Anzahl der Clubs zu überprüfen.
Xeoncross
6
Ich mag diese Abfrage am meisten, weil sie einem sauberen Stil ähnelt, der Python in SQL ähnelt. Ich würde gerne 0,44 ms (anders als bei Seans Abfrage) gegen diese Art von Code eintauschen.
MGP
5

Wenn Sie nur student_id wollen, dann:

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

Wenn Sie auch einen Namen vom Schüler benötigen, dann:

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 )

Wenn Sie mehr als zwei Clubs in einer club_selection-Tabelle haben, dann:

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
quelle
Die ersten beiden sind in meiner Abfrage 1 enthalten. Die dritte behandelt jedoch die hinzugefügte Frage von @Xeoncross in den obigen Kommentaren. Ich würde für diesen Teil ohne die Dupes stimmen.
Erwin Brandstetter
Vielen Dank für den Kommentar, aber ich demonstriere auch einige Formatierungen. Ich werde es so lassen wie es ist.
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)  

Oder eine allgemeinere Lösung, die sich leichter auf nClubs ausweiten lässt und die vermeidet INTERSECT(in MySQL nicht verfügbar) und IN(da die Leistung in MySQL schlecht ist )

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
quelle
Ohne Zweifel ist Ihre zweite Antwort die beste für Abfragen, die vom Code generiert werden. Werde ich ernsthaft 10 Verknüpfungen oder Unterabfragen schreiben, um die relationale Unterteilung von 10 Kriterien zu finden? Nein, ich werde stattdessen diese brillante Lösung verwenden. Vielen Dank, dass Sie mir beigebracht haben, was HAVINGin MySQL funktioniert.
Eric L.
4

Ein weiterer CTE. Es sieht sauber aus, generiert aber wahrscheinlich den gleichen Plan wie ein Groupby in einer normalen Unterabfrage.

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

Für diejenigen, die testen möchten, eine Kopie meines generierten Testdaten-Dings:

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
quelle
Ja, das ist praktisch nur eine Unterabfrage mit group by wie in meiner ersten Version. Gleicher Abfrageplan + CTE-Overhead führt zu gleicher Leistung + ein bisschen für den CTE. Netter Testaufbau.
Erwin Brandstetter
Ich weiß nicht, ob es einen CTE-Overhead gibt. Die Verteilung der Testdaten ist sehr wichtig. Dies gilt auch für die Verfügbarkeit von Statistiken: Nach VACUUM ANALYZE stieg die Laufzeit von 67,4 auf 1,56 ms. Nur Hash und Bitmaps sind am QP beteiligt.
Wildplasser
Das ist etwas Besonderes in Ihrem Fall, nachdem Sie 80% einer großen Tabelle gelöscht und viel aktualisiert haben, hatten Sie mehr tote Tupel als alles andere. Kein Wunder, dass die Vakuumanalyse sehr hilfreich ist. Ich habe beide Varianten mit und ohne CTE ausgeführt, und überraschenderweise waren die Abfragepläne nicht identisch. oder noch besser, ich werde dafür einen Chatraum eröffnen.
Erwin Brandstetter
Keine Sorge, ich wusste über die 80% toten Reihen Bescheid ... Ich denke, die Statistik ist auch wichtig. Das Histogramm ist jedoch eher "flach", da es zufällig gelöscht wird. Vielleicht ist es nur die Schätzung der benötigten Seiten, die sich so stark ändert, dass sich der Planer für einen Planwechsel entscheidet.
Wildplasser
3

Es gibt also mehr als einen Weg, eine Katze zu häuten .
Ich werde zwei weitere hinzufügen , um es vollständiger zu machen.

1) GRUPPE zuerst, später beitreten

Angenommen, ein vernünftiges Datenmodell (student_id, club_id)ist einzigartig in student_club. Martin Smiths zweite Version ist ähnlich, aber er schließt sich zuerst Gruppen später an. Das sollte schneller gehen:

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

Und natürlich gibt es den Klassiker EXISTS. Ähnlich wie Dereks Variante mit IN. Einfach und schnell. (In MySQL sollte dies etwas schneller sein als die Variante mit 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
quelle
3

Da niemand diese (klassische) Version hinzugefügt hat:

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

o.ä:

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

Noch ein Versuch mit einem etwas anderen Ansatz. Inspiriert von einem Artikel in Explain Extended: Mehrere Attribute in einer EAV-Tabelle: 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  
              )
      )

Ein anderer Ansatz:

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ᵀᴹ
quelle
+1 .. schöne Ergänzungen zur nicht ganz so kompletten Catskin-Kollektion! :) Ich habe sie zum Benchmark hinzugefügt.
Erwin Brandstetter
Es ist kein fairer Kampf :) Der große Vorteil einer relationalen Division wie dieser ist, dass der Divisor eine Basistabelle sein kann, so dass das Ändern des Divisors sehr billig ist, dh das Aktualisieren von Zeilen in einer Basistabelle, auf die dieselbe Abfrage abzielt, mit dem Ändern der SQL jedes Mal abfragen.
Tag, wenn
@ErwinBrandstetter: Wäre es möglich, die 3. Variante in Ihren Tests hinzuzufügen?
Ypercubeᵀᴹ
@ypercube: Du hast es verstanden. Ziemlich verdrehte Version. :)
Erwin Brandstetter
1
@Erwin: Wenn Sie es schaffen, etwas Zeit damit zu verschwenden, können Sie auch versuchen, zwei EINZIGARTIGE Schlüssel für beide (stud_id, club_id)und (club_id, stud_id)(oder Primary und Unique) zu haben? Ich denke immer noch, dass für einige dieser Abfragen der Unterschied zwischen 2 und 140 ms zu hoch ist, um durch die Unterschiede in den Ausführungsplänen erklärt zu werden.
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

    ;

Dies scheint recht gut zu funktionieren, da beim CTE-Scan keine zwei separaten Unterabfragen erforderlich sind.

Es gibt immer einen Grund, rekursive Abfragen zu missbrauchen!

(Übrigens: MySQL scheint keine rekursiven Abfragen zu haben.)

Wildplasser
quelle
+1 für die Suche nach einem weiteren halbwegs anständigen Weg dorthin! Ich habe Ihre Anfrage zum Benchmark hinzugefügt. Hoffe das ist ok mit dir. :)
Erwin Brandstetter
Es ist in Ordnung. Aber es war natürlich als Witz gedacht. CTE schneidet tatsächlich gut ab, wenn mehr "streunende" Studenten * Club-Datensätze hinzugefügt werden. (Zum Testen habe ich 1000 Studenten * 100 Clubs verwendet und 80% zufällig gelöscht)
Wildplasser
1

Unterschiedliche Abfragepläne in Abfrage 2) und 10)

Ich habe in einer realen Datenbank getestet, daher unterscheiden sich die Namen von der Katzenhautliste. Da es sich um eine Sicherungskopie handelt, hat sich während aller Testläufe nichts geändert (mit Ausnahme geringfügiger Änderungen an den Katalogen).

Abfrage 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

Abfrage 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
quelle
@wildplasser: Siehe die abweichenden Abfragepläne! Unerwartet für mich. S. 9.0. Der Chatraum war unhandlich, daher missbrauche ich hier eine Antwort.
Erwin Brandstetter
Seltsame Szenen. Grundsätzlich der gleiche QP hier (9.0.1-Beta-Etwas) für den CTE: Seq Scan + Bitmap anstelle eines Index Scan + Merge. Vielleicht ein Fehler in der Kostenheuristik des Optimierers? Ich werde noch einen CTE-Missbrauch produzieren ...
Wildplasser
1

@ erwin-brandstetter Bitte Benchmarking:

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;

Es ist wie Nummer 6) von @sean, nur sauberer, denke ich.

Taai
quelle
2
Sie müssen wissen, dass das @Benachrichtigen nur in Kommentaren funktioniert, nicht in Antworten. Ich bin zufällig auf diesen Beitrag gestoßen. Der Abfrageplan und die Leistung Ihrer Abfrage sind identisch mit Seans Abfrage. Es ist praktisch dasselbe, aber Seans Abfrage mit expliziter JOINSyntax ist die allgemein bevorzugte Form, weil sie klarer ist. +1 für eine weitere gültige Antwort!
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)
    ;

Der Abfrageplan:

 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)

Es scheint also immer noch den seq-Scan des Schülers zu wollen.

Wildplasser
quelle
Ich kann es kaum erwarten zu sehen, ob dies in 9.1 behoben wurde.
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
;

Verwendung der schnellsten Variante (Mr. Sean in Mr. Brandstetter-Tabelle). Kann eine Variante mit nur einem Join sein, nur die student_club-Matrix hat das Recht zu leben. Die längste Abfrage muss also nur mit zwei Spalten berechnet werden. Die Abfrage sollte daher dünn sein.

Stepan Pavlov
quelle
1
Während dieses Code-Snippet die Frage lösen kann, hilft eine Erklärung wirklich , die Qualität Ihres Beitrags zu verbessern. Denken Sie daran, dass Sie in Zukunft die Frage für die Leser beantworten, nicht nur für die Person, die jetzt fragt! Bitte bearbeiten Sie Ihre Antwort, um eine Erklärung hinzuzufügen, und geben Sie an, welche Einschränkungen und Annahmen gelten.
BrokenBinary