∈"> ∉"> ] >
CREATE TABLE PEOPLE (pid INTEGER PRIMARY key,
firstname VARCHAR(30),
lastname VARCHAR(30));
CREATE TABLE MOVIE (mid INTEGER PRIMARY KEY,
title VARCHAR(90) NOT NULL,
year INTEGER NOT NULL,
runtime INTEGER NOT NULL,
rank INTEGER NOT NULL);
CREATE TABLE ROLE (mid INTEGER REFERENCES MOVIE,
pid INTEGER REFERENCES PEOPLE,
name VARCHAR(70),
PRIMARY KEY(mid, pid, name));
CREATE TABLE DIRECTOR (mid INTEGER REFERENCES MOVIE,
pid INTEGER REFERENCES PEOPLE,
PRIMARY KEY (mid, pid));
On peut demander à Postgresql d'afficher le plan qu'il calcule pour une requête avec les esitmations de coût :
EXPLAIN requête;
Dans ce cas, la requête n'est pas évaluée. On peut aussi évaluer la requête :
EXPLAIN ANALYSE requête;
Dans ce cas, la requête est évaluée et les coût réels sont affichés. S'ils divergent des coûts estimés, l'optimiseur s'est trompé, par exemple parce que ses statistiques ne sont pas à jour
On considère:
EXPLAIN ANALYSE SELECT * FROM ROLE,PEOPLE WHERE
ROLE.pid = PEOPLE.pid;
On obtient :
Hash Join (cost=312.07..822.95 rows=14535 width=37)
(actual time=14.799..44.691 rows=14535 loops=1)
Hash Cond: (role.pid = people.pid)
-> Seq Scan on role (cost=0.00..238.35 rows=14535 width=20)
(actual time=0.019..7.570 rows=14535 loops=1)
-> Hash (cost=175.92..175.92 rows=10892 width=17)
(actual time=14.711..14.711 rows=10892 loops=1)
-> Seq Scan on people (cost=0.00..175.92 rows=10892 width=17)
(actual time=0.015..5.944 rows=10892 loops=1)
Seq Scan on people (cost=0.00..175.92 rows=10892 width=17)
(actual time=0.015..5.944 rows=10892 loops=1)
(cost=0.00..175.92 rows=10892 width=17)
(actual time=0.015..5.944 rows=10892 loops=1)
Hash Join (cost=…) (actual time=…)
Hash Cond: (role.pid = people.pid)
-> Seq Scan on role (cost=…) (actual time=…)
-> Hash (cost=…) (actual time=…)
-> Seq Scan on people (cost=…) (actual time=…)
Note: les projections n'apparaissent pas, on peut les voir avec EXPLAIN ANALYSE VERBOSE.
Les opérateurs sont déclinés selon les différents algorithmes (jointure, tris, …)
(Cours 5) si l'index est non-groupant, l'utilisation de l'index peut provoquer une séquence de chargement/déchargement de pages ruinant les performances
Solution en deux phases
Intéret: Un bitmap est petit (si la relation contient 10000 pages, le bitmap contient 10000 bits ou environs 1250 octets (soit moins d'une page).
Cela permet aussi de répondre efficacement aux requêtes booléenes complexes (i.e. autre qu AND). En effet on calcule un bitmap pour chaque sous-condition, et on fait les opérations entre bitmap bit à bit.