PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Wie man eine EXPLAIN-ANALYSE versteht

Obwohl es für einen einfachen Plan wie diesen nicht so nützlich ist, ist http://explain.depesz.com wirklich nützlich. Siehe http://explain.depesz.com/s/t4fi. Beachten Sie die Registerkarte "Statistiken" und das Pulldown-Menü "Optionen".

Hinweise zu diesem Plan:

  • Die geschätzte Zeilenzahl (183) ist einigermaßen vergleichbar mit der tatsächlichen Zeilenzahl (25). Es ist nicht hundertmal mehr und auch nicht 1. Sie interessieren sich mehr für Größenordnungen, wenn es um Schätzungen der Zeilenanzahl oder um „1 vs. nicht 1“-Probleme geht. (Sie brauchen nicht einmal die Genauigkeit "nah genug für Regierungsarbeit" - "nah genug für die Buchhaltung von Militäraufträgen" reicht aus). Die Selektivitätsschätzung und Statistiken erscheinen vernünftig.

  • Es verwendet den bereitgestellten zweispaltigen Teilindex (index scan using index_cars_onsale_on_brand_and_model_name ), also stimmt es mit der partiellen Indexbedingung überein. Das sieht man im Filter: has_auto_gear . Die Index-Suchbedingung wird ebenfalls angezeigt.

  • Die Abfrageleistung sieht vernünftig aus, wenn man bedenkt, dass die Zeilenanzahl der Tabelle bedeutet, dass der Index ziemlich groß ist, insbesondere da er sich über zwei Spalten erstreckt. Übereinstimmende Zeilen werden verstreut sein, daher ist es wahrscheinlich, dass für jede Zeile auch eine separate Seite gelesen werden muss.

Ich sehe hier nichts Falsches. Diese Abfrage wird jedoch wahrscheinlich stark von den Nur-Index-Scans von PostgreSQL 9.2 profitieren.

Es ist möglich, dass es hier zu einer Tabellenaufblähung kommt, aber angesichts des 2-Spalten-Index und der schieren Anzahl von Zeilen ist die Antwortzeit nicht ganz unvernünftig, insbesondere für eine Tabelle mit 170 (!!) Spalten, in die wahrscheinlich relativ wenige Tupel passen Seite. Wenn Sie sich etwas Ausfallzeit leisten können, versuchen Sie es mit VACUUM FULL um die Tabelle neu zu organisieren und den Index neu zu erstellen. Dadurch wird die Tabelle für einige Zeit exklusiv gesperrt, während sie neu erstellt wird. Wenn Sie sich die Ausfallzeit nicht leisten können, lesen Sie pg_reorg und/oder CREATE INDEX CONCURRENTLY und ALTER INDEX ... RENAME TO .

Möglicherweise finden Sie EXPLAIN (ANALYZE, BUFFERS, VERBOSE) manchmal informativer, da es Pufferzugriffe usw. anzeigen kann.

Eine Möglichkeit, diese Abfrage schneller zu machen (obwohl dadurch andere Abfragen etwas verlangsamt werden könnten), besteht darin, die Tabelle nach brand zu partitionieren und aktivieren Sie constraint_exclusion . Siehe Partitionierung.