Gedeelde hitcache in postgreSQL

shared hit betekent in wezen dat de waarde al in het hoofdgeheugen van de computer is opgeslagen en dat het niet nodig was om deze van de harde schijf te lezen.

Toegang tot het hoofdgeheugen (RAM) is veel sneller dan het lezen van waarden van de harde schijf. En daarom is de zoekopdracht sneller naarmate hij meer gedeelde hits heeft.

Direct na het starten van Postgres is geen van de gegevens beschikbaar in het hoofdgeheugen (RAM) en moet alles van de harde schijf worden gelezen.

Overweeg deze stap vanuit een uitvoeringsplan:

  ->  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

Het onderdeel "Buffers:shared read=2818" betekent dat 2818 blokken (elk 8k) van de harde schijf moesten worden gelezen (en dat duurde 48ms - ik heb een SSD). Die 2818 blokken werden opgeslagen in de cache (de "gedeelde buffers ") zodat de database de volgende keer dat ze nodig zijn ze niet (opnieuw) van de (trage) harde schijf hoeft te lezen.

Als ik die verklaring opnieuw uitvoer, verandert het plan in:

  ->  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

Dat betekent dat die 2818 blokken die het vorige statement nog in het hoofdgeheugen (=RAM) zaten en Postgres ze niet van de harde schijf hoefde te lezen.

"geheugen" verwijst altijd naar het hoofdgeheugen (RAM) dat in de computer is ingebouwd en direct toegankelijk is voor de CPU - in tegenstelling tot "externe opslag".

Er zijn verschillende presentaties over hoe Postgres de gedeelde buffers beheert: