Une table organisée par index peut-elle accélérer le processus SELECT COUNT (*) FROM table

Question

Je trouve qu'il est compliqué de créer un déclencheur juste pour obtenir le nombre total de lignes de la table sans la table COUNT (*) FROM. Je pense que leurs tables planifiées par index pour Postgres 8.5 pourraient le rendre possible?

Answer 1

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

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

Vous pouvez également placer [xmin, xmax] dans l'index - des suggestions pour ce type de mise en place de temps en temps. Mais cela gonfle les indices, et pour être utile, toutes les mises à jour/suppressions doivent s'assurer qu'elles sont mises à jour: et cela pose des problèmes, notamment parce que le travail impliqué dans la mise à jour a été multiplié par plusieurs par le nombre d'indices sur la table. Dans le cas d'indices 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, avec des lignes apparaissant dans l'index, mais mortes dans l'index. tas. Et tout le but de cet exercice était censé être de permettre à la base de données de s'appuyer exclusivement sur l'information de direct dans l'index, si possible. Ce coût serait encouru même si vous étiez en train de mettre à jour une colonne non indexée - quelque chose que l'équipe a fait un effort pour accélérer en 8.3 (tuples tas-seul). Je suppose qu'une possibilité consisterait à marquer des indices comme ayant éventuellement [xmin, xmax] - par exemple,

marque seulement l'index pkey de cette façon. Ensuite, il devrait y avoir des changements de planificateur pour comprendre quand c'était un avantage --- il semble que beaucoup 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 clusterisé est organisé par index) fonctionnent en stockant [clé, tuple] dans l'index de clé primaire à la place (et probablement [clé, pkey] dans tous les autres) - pas de ctid, pas de tas. Donc "tuple" contiendra [xmin, xmax, cminmax, natts, ....] etc et vous pourriez satisfaire le "select count (*) de la table" juste en balayant l'index. Mais c'est essentiellement la même chose que l'analyse des tuples sur le tas --- ils ne prennent pas par magie moins d'espace parce qu'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 prendra 1 page au lieu de 3, et les analyses d'index par clé primaire peuvent être un peu plus rapides. Je crois me souvenir que le conseil relatif à Oracle pour les IOT était qu'ils étaient destinés à des tables de dimension statiques, et non à un usage général, en partie à cause du coût imposé pour maintenir les indices secondaires (je ne pense pas qu'Oracle stocke [ key, pkey] dans les indices secondaires IOT, mais plutôt une sorte d'alternative rowid).

Answer 2

Cela est très daté, mais avec PostgreSQL 9.2, vous obtenez des analyses d'index seulement qui peuvent également effectuer count (*).

Voir aussi,

• Is "count(*)" much faster now?