versteht Postgres

Question

explain analyse 
SELECT COUNT(*) FROM syo_event WHERE id_group = 'OPPORTUNITY' AND id_type = 'NEW' 

Meine Abfrage diesen Plan hat:

Aggregate (cost=654.16..654.17 rows=1 width=0) (actual time=3.783..3.783 rows=1 loops=1) 
    -> Bitmap Heap Scan on syo_event (cost=428.76..654.01 rows=58 width=0) (actual time=2.774..3.686 rows=1703 loops=1) 
     Recheck Cond: ((id_group = 'OPPORTUNITY'::text) AND (id_type = 'NEW'::text)) 
     -> BitmapAnd (cost=428.76..428.76 rows=58 width=0) (actual time=2.635..2.635 rows=0 loops=1) 
       -> Bitmap Index Scan on syo_list_group (cost=0.00..35.03 rows=1429 width=0) (actual time=0.261..0.261 rows=2187 loops=1) 
        Index Cond: (id_group = 'OPPORTUNITY'::text) 
       -> Bitmap Index Scan on syo_list_type (cost=0.00..393.45 rows=17752 width=0) (actual time=2.177..2.177 rows=17555 loops=1) 
        Index Cond: (id_type = 'NEW'::text) 
Total runtime: 3.827 ms 

In der ersten Zeile:

(actual time=3.783..3.783 rows=1 loops=1 

(Warum die aktuelle Zeit nicht mit der letzten Zeile passen, Total runtime ?)

In der zweiten Zeile:

cost=428.76..654.01 

(Starten Sie die Bitmap Heap Scan mit Kosten 428,76 und endet mit 654,01)?

rows=58 width=0) 

(Wath ist rows und width, alles wichtig?)

rows=1703 

(dies ist das Ergebnis)

loops=1) 

(Used in Subqueries?)

Answer 1

Was die erste Zeile, EXPLAIN die Abfrage ausgeführt und es dauerte 3.783 ms, aber Sie mit dem Ausgang des Plans präsentiert nimmt einige Zeit in Anspruch, so dass der Gesamt Die Laufzeit erhöht sich um die dafür benötigte Zeit.

---

Grundsätzlich EXPLAIN ANALYZE Displays schätzt, dass eine einfache EXPLAIN Sie zusammen mit den Werten aus tatsächlich läuft die Abfrage gesammelt zeigen würde, daher der Unterschied in der Sekunden Linie.

---

Beide Zeilen und Breite sind wichtig. Dies ist jeweils die Anzahl der Zeilen-Ausgabeschätzungen und eine durchschnittliche Zeilenbreite in Bytes. Ihre geschätzten Gesamtkosten sind niedriger, wenn die Schätzung der zurückgegebenen Zeilen kleiner ist und Sie dies berücksichtigen müssen.

---

Um zu verstehen, was tatsächlich präsentieren Sie wissen müssen, um Loops, die ein Abfrage-Plan tatsächlich ein Baum von Plan Knoten ist.Es gibt verschiedene Arten von Knoten, die verschiedenen Zwecken dienen - beispielsweise ist ein Scan-Knoten dafür verantwortlich, unformatierte Zeilen aus einer Tabelle zurückzugeben. Wenn Ihre Abfrage eine Operation für Zeilen ausführt, befinden sich zusätzliche Knoten über den Scan-Knoten, um dies zu behandeln.

Die erste Zeile in Ihrer Ausgabe von EXPLAIN ist eine Zusammenfassung vom Knoten der Ebene 1 (oben) mit geschätzten Kosten für den gesamten Plan.

Wissen, Schleifen stellt einen Wert der Gesamtzahl der Ausführungen eines bestimmten Knotens. Dies liegt daran, dass in einigen Plänen ein Teilplanknoten mehr als einmal ausgeführt werden kann. Wenn dies geschieht, multipliziert er die Zeit- und Zeilenwerte mit Schleifen, um die Gesamtzeit zu erhalten, die in diesem Knoten verbracht wurde.

---

Sie können mehr Einblick in das Thema in der documentation erhalten.

Answer 2

Von der postgres docs:

Beachten Sie, dass die "tatsächlichen Zeit" -Werte in Millisekunden Echtzeit sind, während die Kostenschätzungen in willkürlichen Einheiten ausgedrückt werden; also werden sie wahrscheinlich nicht zusammenpassen. Die wichtigste Sache, nach der man suchen sollte, ist, ob die geschätzten Zeilenzahlen einigermaßen nahe an der Realität liegen.

Die geschätzten Kosten werden berechnet als (gelesene Festplattenseiten * seq_page_cost) + (gescannte Zeilen * cpu_tuple_cost). Standardmäßig ist seq_page_cost 1.0 und cpu_tuple_cost ist 0,01