Des tables organisées par index pourraient-elles paver la voie pour une sélection plus rapide de SELECT COUNT (*) FROM table

Question

Je trouve fastidieux de créer un déclencheur juste pour obtenir le nombre total de lignes de la table en cours sans faire COUNT (*) FROM table. Je pense que si leurs tables organisées par index pour Postgres 8.5 pourraient rendre cela possible?

Answer 1

Je n'aurais pas pensé qu'une table organisée par index serait nécessairement plus rapide à analyser pour compter tous les n-uplets visibles. Logiquement, il devrait passer par la même quantité de données, qu’elle soit organisée de sorte que les données se trouvent dans les nœuds de feuille b-tree ou dans le format de segment de mémoire existant.

Actuellement, les index postgresql ne stockent que des paires [clé, ctid] (essentiellement). (Un ctid est essentiellement un "rowid" - numéro de page de tas et index de pointeur de ligne de tuples) Ainsi, vous ne pouvez pas compter les lignes de la table simplement en parcourant l'index, car vous devez vérifier [xmin, xmax] pour chaque tuple-- et c'est seulement gardé avec les données, dans le tas.

Vous pouvez également ajouter [xmin, xmax] dans l'index - des suggestions pour ce recadrage de temps en temps. Mais cela alourdit les index et pour que toutes les mises à jour / suppressions soient utiles, il faudrait s’assurer de leur mise à jour: ce qui pose problème, notamment parce que le travail de mise à jour a été multiplié par plusieurs. par le nombre d'indices sur la table. Dans le cas d'index lourds tels que tsvector ou basés sur des expressions utilisateur coûteuses, cela peut prendre un certain temps et, dans certains cas désagréables, ne pas fonctionner du tout, les lignes apparaissant désormais comme étant vivantes dans l'index, mais mortes dans la liste. tas. Et le but de cet exercice était censé être de permettre à la base de données de s’appuyer exclusivement, si possible, sur les informations relatives à la qualité de vie figurant dans l’index. Ce coût serait engagé même si vous mettiez à jour une colonne non indexée, ce que l'équipe a tenté de faire pour accélérer au plus vite en 8.3 (tuples uniquement pour les tas).

Je suppose qu’une possibilité serait de marquer les indices comme ayant éventuellement [xmin, xmax] - par ex. Ne marquez l’index pkey de cette façon. Il faudrait ensuite que le planificateur soit modifié pour déterminer à quel moment il s’agissait d’un avantage - cela semble un peu de travail.

Les tables organisées par index, si elles fonctionnent comme je le crois dans Oracle (et SQL Server, où toute table avec un index en cluster est essentiellement organisé par index) fonctionnent en stockant [clé, tuple] dans l'index de clé primaire (et vraisemblablement [key, pkey] dans tous les autres) - pas de ctid, pas de tas. Donc, "tuple" contiendra [xmin, xmax, cminmax, natts, ....], etc. et vous pourrez satisfaire le "nombre de sélections (*) de la table" simplement en parcourant l'index. Mais cela revient essentiellement à scanner les n-uplets sur le tas - ils ne prennent pas magiquement moins de place car ils sont maintenant dans un "index".

AFAICT La raison principale pour une table organisée par index est qu'une petite table avec un seul index de clé primaire occupera une page au lieu de 3 et que les analyses d'index par clé primaire seront un peu plus rapides. Je semble me souvenir que les conseils concernant les IOT concernant Oracle, c’est qu’ils étaient destinés à des tables de dimensions statiques et non à une utilisation générale, en partie à cause du coût imposé à la maintenance des index secondaires (je ne pense pas que les magasins Oracle soient stockés [ key, pkey] dans les index secondaires IOT, mais plutôt une sorte de rowid alternatif).

Answer 2

Ceci est daté, mais avec PostgreSQL 9.2, vous obtenez des analyses d’index uniquement qui peuvent également effectuer un décompte (*).

Voir aussi,

• Is " count (*) " beaucoup plus vite maintenant?