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

Gemeinsamer Treffer-Cache in PostgreSQL

shared hit bedeutet im Wesentlichen, dass der Wert bereits im Hauptspeicher des Computers zwischengespeichert wurde und nicht von der Festplatte gelesen werden musste.

Der Zugriff auf den Hauptspeicher (RAM) ist viel schneller als das Lesen von Werten von der Festplatte. Und deshalb ist die Abfrage umso schneller, je mehr Share-Treffer sie hat.

Direkt nach dem Start von Postgres sind keine Daten mehr im Arbeitsspeicher (RAM) vorhanden und es muss alles von der Festplatte gelesen werden.

Betrachten Sie diesen Schritt aus einem Ausführungsplan:

  ->  Seq Scan on products.product_price  (cost=0.00..3210.27 rows=392273 width=0) (actual time=0.053..103.958 rows=392273 loops=1)
        Output: product_id, valid_from, valid_to, price
        Buffers: shared read=2818
        I/O Timings: read=48.382

Der Teil „Buffers:shared read=2818“ bedeutet, dass 2818 Blöcke (je 8k) von der Festplatte gelesen werden mussten (und das hat 48ms gedauert – ich habe eine SSD). Diese 2818 Blöcke wurden im Cache gespeichert (der "gemeinsam genutzte Puffer "), damit die Datenbank sie beim nächsten Mal nicht (erneut) von der (langsamen) Festplatte lesen muss.

Wenn ich diese Anweisung erneut ausführe, ändert sich der Plan zu:

  ->  Seq Scan on products.product_price  (cost=0.00..3210.27 rows=392273 width=0) (actual time=0.012..45.690 rows=392273 loops=1)
        Output: product_id, valid_from, valid_to, price
        Buffers: shared hit=2818

Das bedeutet, dass die 2818 Blöcke, die die vorherige Anweisung noch im Hauptspeicher (=RAM) hatte und Postgres sie nicht von der Festplatte lesen musste.

„Arbeitsspeicher“ bezieht sich immer auf den im Computer eingebauten Arbeitsspeicher (RAM), auf den die CPU direkt zugreifen kann – im Gegensatz zu „externem Speicher“.

Es gibt mehrere Präsentationen darüber, wie Postgres die gemeinsam genutzten Puffer verwaltet: