J'étais curieux. Et comme nous le savons tous, la curiosité a la réputation de tuer les chats.
Alors, quel est le moyen le plus rapide d'écorcher un chat?
L'environnement précis de peau de chat pour ce test:
- PostgreSQL 9.0 sur Debian Squeeze avec une RAM et des paramètres décents.
- 6.000 étudiants, 24.000 adhésions à des clubs (données copiées à partir d'une base de données similaire avec des données réelles.)
- Léger détournement du schéma de dénomination dans la question:
student.idest student.stud_idet club.idest club.club_idici.
- J'ai nommé les requêtes d'après leur auteur dans ce fil, avec un index où il y en a deux.
- J'ai exécuté toutes les requêtes plusieurs fois pour remplir le cache, puis j'ai choisi le meilleur des 5 avec EXPLAIN ANALYZE.
Index pertinents (devrait être l'optimum - tant que nous ne savons pas quels clubs seront interrogés):
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_pkeyn'est pas requis par la plupart des requêtes ici.
Les clés primaires implémentent automatiquement des index uniques dans PostgreSQL.
Le dernier index est de compenser cette lacune connue des index multi-colonnes sur PostgreSQL:
Un index B-tree multicolonne peut être utilisé avec des conditions de requête qui impliquent n'importe quel sous-ensemble des colonnes de l'index, mais l'index est plus efficace lorsqu'il existe des contraintes sur les colonnes de début (les plus à gauche).
Résultats:
Durée totale d'exécution de 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;
Les trois derniers fonctionnent à peu près de la même manière. 4) et 5) aboutissent au même plan de requête.
Ajouts tardifs:
Fantaisie SQL, mais les performances ne peuvent pas suivre.
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
)
);
Comme prévu, ces deux performances sont presque identiques. Le plan de requête entraîne des analyses de table, le planificateur ne trouve pas un moyen d'utiliser les index ici.
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;
Fantaisie SQL, performances décentes pour un CTE. Plan de requête très exotique.
Encore une fois, il serait intéressant de savoir comment la 9.1 gère cela. Je vais bientôt mettre à niveau le cluster de base de données utilisé ici vers la version 9.1. Peut-être que je vais relancer tout le 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);
Variante CTE de la requête 2). Étonnamment, cela peut entraîner un plan de requête légèrement différent avec exactement les mêmes données. J'ai trouvé une analyse séquentielle sur student, où la variante de sous-requête a utilisé l'index.
11) ypercube 3: 101,482 ms
Un autre ajout tardif @ypercube. C'est vraiment incroyable, combien il y a de façons.
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) n'est en fait que l'approche inversée stupéfiante de cette variante plus simple, qui manquait également. Fonctionne presque aussi vite que les meilleurs chats.
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
Difficile à croire, mais voici une autre variante véritablement nouvelle. Je vois un potentiel pour plus de deux adhésions, mais il se classe également parmi les meilleurs chats avec seulement deux.
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
)
Nombre dynamique d'adhésions au club
En d'autres termes: un nombre variable de filtres. Cette question demandait exactement deux adhésions au club. Mais de nombreux cas d'utilisation doivent se préparer à un nombre variable.
Discussion détaillée dans cette réponse ultérieure connexe: