Forums PostgreSQL.fr

dverite

Membre

Re : HashAggregate to slow

Le CLUSTER ne marche pas chez moi,  pourtant je suis ssur la 9.1.
Peut-être que c'est par ce que ma table est une partition!

Ou bien c'est pour la raison indiquée dans le message d'erreur que nous ne pouvons pas deviner, faute d'être télépathe.

---

@DanielVerite
http://blog-postgresql.verite.pro/

gleu

Administrateur

Re : HashAggregate to slow

Cette solution ne fonctionne pas avec PostgreSQL. Avant la version 9.2 (en beta depuis deux semaines), PostgreSQL est obligé de lire l'index et la table lors d'un parcours d'index, quelque soit ce parcours d'index (Index Scan ou Bitmap Index Scan).

---

Guillaume.

Postgres.0

Membre

Re : HashAggregate to slow

Cette solution ne fonctionne pas avec PostgreSQL. Avant la version 9.2 (en beta depuis deux semaines), PostgreSQL est obligé de lire l'index et la table lors d'un parcours d'index, quelque soit ce parcours d'index (Index Scan ou Bitmap Index Scan).

Bonjour gleu,

serait-il possible de m'expliquer ce que vous voulez dire par la.

Si PG est obligé de lire la table et l'index, à qoui sert donc de faire un index scan, pour quoi pas un seq scan.

Y a t-il d'autre SGBD qui ne lisent pas la table et l'index lors d'un index scan, comment font ils?

quelle difference y a t-il entre Index Scan et Bitmap index Scan?
J'ai cru comprendre que lors de Bitmap PG trie les adresses physiques des bloques avant d'aller chercher les lignes de la tables, pouvez m'expliquer en detail.

Merci

rjuju

Administrateur

Re : HashAggregate to slow

Jusqu'en 9.1, Postgresql était obligé de chercher les informations de visibilité des lignes dans la table lors d'un parcours d'index car celles-ci n'étaient pas présentes dans l'index. Les informations de visibilité ont été rajoutées en 9.2, il est donc possible de faire un parcours d'index seul à partir de cette version (qui devrait sortir d'ici peu).

Pour les Bitmap Index Scan, le principe est le suivant :
* L'index est parcouru en une seule fois pour construire un bitmap trié par adresse physique des lignes de la table pour les lignes correspondant au filtre
* La table est parcourue, de manière séquentielle grâce au bitmap, pour chercher les lignes correspondantes

Si vous voulez une explication vraiment détaillée, vous pouvez écouter cette conférence :
https://www.pgcon.org/2010/audio/15%20T … lanner.mp3

---

Julien.
https://rjuju.github.io/

gleu

Administrateur

Re : HashAggregate to slow

Attention, en 9.2, les informations de visibilité n'ont pas été ajoutées dans les index. Mais il existe une 9.2 un mécanisme fiable permettant de faire à peu près la même chose.

Pour répondre plus en détail à Postgres.0

Si PG est obligé de lire la table et l'index, à qoui sert donc de faire un index scan, pour quoi pas un seq scan.

Il peut ne lire qu'une partie de l'index, et surtout il ne lira qu'une petite partie de la table. Par exemple, si vous faites un "SELECT * FROM t1 WHERE c1=10000" et que votre table fait 100000 blocs (donc 800 Mo en gros), PostgreSQL va chercher rapidement dans l'index où se trouve la ligne où c1=10000 dans la table (généralement, cela occasionne la lecture de 3/4 blocs), puis ira lire les blocs contenant cette ligne dans la table. Si jamais cela ne représente qu'une ligne (clé primaire par exemple), ça ne fait lire qu'un bloc de la table. Autrement dit, au lieu de faire un parcours complet de la table (100000 blocs, soit 800 Mo dans notre exemple), je ne lis plus que 4 à 5 blocs (soit 40 Ko maximum). Je suppose que vous voyez l'avantage indéniable de l'index ici Si évidemment toute la table contient la valeur 100000 dans la colonne c1, utilisez l'index ne sert à rien. En fait, c'est même pire, ça fait perdre du temps. Si les statistiques sur les données sont bonnes, PostgreSQL fera un parcours séquentiel, et non pas un parcours d'index.

Y a t-il d'autre SGBD qui ne lisent pas la table et l'index lors d'un index scan, comment font ils?

Il me semble qu'Oracle ne le fait pas, mais j'avoue ne pas en savoir beaucoup plus.

PostgreSQL le fait beaucoup moins souvent en 9.2.

quelle difference y a t-il entre Index Scan et Bitmap index Scan?

Les éléments de l'index sont représentés sous la forme d'un champ de bits. Du coup, pour mixer deux index, il suffit d'une opération binaire, ce qui est très rapide. Généralement, l'index bitmap est intéressant dans les cas où le nombre de lignes est trop important pour utiliser un parcours d'index et trop faible pour utiliser un parcours de table.

---

Guillaume.

Postgres.0

Membre

Re : HashAggregate to slow

Merci beaucoup rjuju

quelle est donc la structure de donnée qui correspond au bitmap.

Postgres.0

Membre

Re : HashAggregate to slow

Merci bcp gleu

gleu

Administrateur

Re : HashAggregate to slow

quelle est donc la structure de donnée qui correspond au bitmap

Suivant le nombre de lignes, cela sera soit un bit par ligne, soit un bit par bloc. Le deuxième cas cause une opération de vérification après coup (car un bloc contient souvent plusieurs lignes).

---

Guillaume.