Discussion :

[k o D]

Bonjour à tous.

Ma question va sans doute vous sembler bête mais j'ai un peu de mal à comprendre pourquoi PostgreSQL n'utilise pas un INDEX que j'ai créé pour une de mes requêtes.

Voici ma table:

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE Bareme (
	id int8 not null,
    montant numeric(19, 2) not null,
    uniteFrequence varchar(255) not null,
    dateDebutValidite timestamp not null,
    dateFinValidite timestamp,
    numeroPoste varchar(255) not null
);

Voici l'index que j'ai créé:

Code :

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

CREATE INDEX bareme_numeroPoste_idx ON Bareme (numeroPoste);

Et voici le query effectué:

Code :

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

select * from bareme where numeroPoste = '006'

Malgré cela, je remarque en effectuant un "Query Plans" qu'il fait toujours un "Seq Scan on bareme".

Il est vrai que je ne peux pas me permettre de créer l'index comme ceci:

Code :

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

CREATE UNIQUE INDEX bareme_numeroPoste_idx ON Bareme (numeroPoste);

Puisque plusieurs barèmes peuvent être sur le même numéro de poste.

Alors comme je suis novice dans le monde des SGBD, je vais vous expliquer comment je vois l'index parce que ça peut être la cause de mon "problème".
Pour moi, en créant celui que j'ai fait plus haut, PostgreSQL a créé X ensembles de row où X correspond au nombre d’occurrences différentes de mon numeroPoste.

Ainsi si j'avais ceci:

Code :

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

1
2
3
4
Bareme 1 => numeroPoste = 1
Bareme 2 => numeroPoste = 1
Bareme 3 => numeroPoste = 1
Bareme 4 => numeroPoste = 2

Je me serai retrouvé avec 2 ensembles.
Le premier étiqueté "numeroPoste = 1" contenant 3 rows et le second "numeroPoste = 2" contenant 1 seul row.

Et de cette manière, en passant par cet index pour récupérer l'ensemble des row dont le numeroPoste = 2, PostgreSQL n'aurait eu qu'à regarder au plus 2 étiquettes d'ensemble.

Si ce que j'explique est réellement ce qui est fait, alors je ne vois pas pourquoi PostgreSQL n'utilise pas mon index puisqu'il va lui simplifier la tâche...

Merci d'avance pour votre réponse.

[vmolines]

La lecture de la table a du être estimée plus rapide que la lecture de l'index puis la lecture des lignes trouvées. Donnez le plan d'exécution complet.

[k o D]

Seq Scan on bareme (cost=0.00..2.03 rows=9 width=40) (actual time=0.019..0.040 rows=9 loops=1)
Filter: ((numeroposte)::text = '006'::text)
Total runtime: 0.071 ms

Maintenant il est vrai que je n'ai pas énormément de rows dans ma DB (82)

[k o D]

Effectivement, si j'ajoute un certain nombre de barèmes supplémentaires, il va faire ceci:

Code :

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

1
2
3
4
5
Bitmap Heap Scan on bareme  (cost=4.95..16.07 rows=90 width=40) (actual time=0.061..0.095 rows=117 loops=1)
  Recheck Cond: ((numeroposte)::text = '006'::text)
  ->  Bitmap Index Scan on bareme_numeroposte_idx  (cost=0.00..4.93 rows=90 width=0) (actual time=0.050..0.050 rows=117 loops=1)
        Index Cond: ((numeroposte)::text = '006'::text)
Total runtime: 0.137 ms

[vmolines]

Résolu ?

[k o D]

En effet.
Merci