Discussion :

[inarus]

Bonjour à tous,

On m'a soumis un exercice concernant les bases de données.
J'ai beau chercher, je ne comprends pas le résultat.

On a deux bases de donnée avec les même tables et les même données dedans.
Seule la table 'toto' diffère
Pour la 1ere base de donnée : le champ A (integer) est déclaré comme clef primaire.
Pour la 2eme base de donnée : il n'y a pas de clef primaire.

On réalise la requête suivante sur chacune des deux bases:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

explain ANALYZE select * from toto where A*12=420;

Les "counts" sont identiques.
Temps de réponse pour la 1ere base : 7 secondes (seq scan)
Temps de réponse pour la 2eme base : 0.7 secondes (seq scan)


J'ai beau chercher, je ne comprends pas pourquoi il y a un écart de temps de réponse si différent.

Est-ce que quelqu'un aurait une explication et/ou une référence sur ce sujet ?

Merci,
Inarus

[CinePhil]

Faut vraiment être prof pour inventer une requête pareille !

Tu es sûr que c'est la table sans clé primaire qui donne la requête la plus lente ?

WHERE A*12=420 <==> WHERE A = 35
Le SGBD doit pouvoir, je pense, transformer la requête et utiliser l'index sur A pour trouver beaucoup plus rapidement les lignes de clé 35 alors que sans index il doit parcourir toute la table.

[inarus]

Merci pour ta réponse .

Tu es sûr que c'est la table sans clé primaire qui donne la requête la plus lente ?

Oui , justement c'est cela qui me pose un problème .

Le SGBD doit pouvoir, je pense, transformer la requête et utiliser l'index sur A pour trouver beaucoup plus rapidement les lignes de clé 35 alors que sans index il doit parcourir toute la table.

Dans le plan de requête donné , le SGBD fait un seq scan (analyse séquentielle) pour les deux tables (avec ou sans la clé définie).

[StringBuilder]

Je pense qu'il ne faut pas chercher une règle générale à ce comportement.

Tout du moins, pas au niveau de la structure.

Cette table est-elle volumineuse ?

En effet, j'aurais plutôt tendance à dire que si la table est peu volumineuse, le SGBD la charge intégralement en mémoire.

Par conséquent, index ou pas, la recherche de lignes à partir d'un simple critère sera à peu de chose près aussi rapide, index ou non.

En revanche, si un index est présent, alors si le SGBD décide malencontreusement d'utiliser ce dernier, alors il va trouver la ligne en deux fois :
- Une lecture dans l'index (qui va prendre presque autant de temps qu'une lecture dans la table entière si cette dernière est petite et en mémoire)
- Une seconde lecture dans la table, afin de retrouver les lignes dont le rowid correspond à ceux trouvés dans l'index.

Et on se rend compte à ce moment que le SGBD travaille deux fois plus s'il utilise l'index.

Même mieux, si le SGBD est limite en mémoire, il va peut-être charger en mémoire uniquement l'index de la table, et pas la table elle-même, alors qu'il aurait peut-être eu la place de charger la table s'il n'y avait pas eu d'index.

Cependant, une fois de plus, attention à ne pas tirer de conclusions hâtives et généralistes, car notamment certains SGBD peuvent décider eux-même d'utiliser ou non un index, car ils ne sont pas stupide, et savent qu'un index peut faire perdre du temps sur de petits volumes.

Après, je suis pas DBA, il y a peut-être d'autres explications.

[SQLpro]

Tout dépend :

• du SGBDR utilisé,
• de son optimiseur,
• des statistiques (et si elles sont à jour),
• de la structure de la table,
• de la volumétrie des données
• et de la distribution des données !

Ce qui fait beaucoup de paramètres...
Bref, cet exercice dans les conditions évoquées est d'une haute stupidité ou bien vous ne nous avez pas assez renseigné sur le problème.

A +

[inarus]

- Les statistiques sont à jour .

- La table a une taille de 2000 tuples donc en effet elle n'est pas très volumineuse.

- Les requêtes ont été effectués grâce à postgres .

- les coûts sont identiques seul le "actual time " diffère.

Voilà c'est tout ce que j'ai pu oublier de dire .

StringBuilder : Est ce lors d'un parcours séquentielle , le SGBD charge toujours l'ensemble de la table en mémoire ?



voici les informations exactes que je possède à part la taille de la table (2000 tuples) :

1 ère table (avec clé primaire sur A) :

Seq Scan on toto (cost=0.00..49.00 rows=10 width=43) (actual time=0.037..23.863 rows=1 loops=1)
Filter: ((A * 10) = 900)
Total runtime: 23.888 ms

2 ème table (sans clé défini) :

Seq Scan on toto (cost=0.00..49.00 rows=10 width=43) (actual time=0.034..0.567 rows=1 loops=1)
Filter: ((A* 10) = 900)
Total runtime: 0.586 ms

[punkoff]

Ca n'a pas de sens.


Si on part du postulat que les deux bdd :
- sont sur des serveurs avec archi identique
- que la conf des deux bases est identique
- que les deux tables sont identiques
- que rien n’interfère avec ces bdd


En faisant un WHERE A/12 = 420 vous court-circuitez la seule possibilité à PostGresql de changer de plan d’exécution ... et du coup d'avoir un temps d'exec différent.

Les temps devrait donc être presque identique sur vos deux requêtes.

[Rei Ichido]

Deux bases différentes, et les instructions de lancement sont lancées à chaque fois sur la base elle-même ? La différence pourrait venir d'une liaison réseau. Ou bien du temps de parsing si la requête n'est pas en cache, si vous réitérez le select, quel est le temps ? [cela dit, on aura d'autres biais]

[CinePhil]

Et si, en réinitialisant le serveur, on lance les requêtes dans l'ordre inverse - sans clé d'abord et avec ensuite, les résultats sont-ils identiques ?

[inarus]

Merci beaucoup pour l’intérêt que vous portez à mon problème .

Je vais essayer de faire la requête en réinitialisant la base de données et en faisant les requêtes dans l'autre sens pour voir si cela change ou même inverse les temps.

Je vous tiens au courant .