shared hit betyder i huvudsak att värdet redan har cachats i datorns huvudminne och att det inte var nödvändigt att läsa detta från hårddisken.
Åtkomst till huvudminnet (RAM) är mycket snabbare än att läsa värden från hårddisken. Och det är därför frågan är snabbare ju fler andel träffar den har.
Direkt efter start av Postgres finns ingen av datan tillgänglig i huvudminnet (RAM) och allt behöver läsas från hårddisken.
Överväg detta steg från en genomförandeplan:
-> 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
Delen "Buffertar:delad läsning=2818" betyder att 2818 block (varje 8k) måste läsas från hårddisken (och det tog 48ms - jag har en SSD). Dessa 2818 block lagrades i cachen (delade buffertar ") så att nästa gång de behövs behöver databasen inte läsa dem (igen) från den (långsamma) hårddisken.
När jag kör om det uttalandet ändras planen till:
-> 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
Vilket betyder att de där 2818 blocken som det tidigare uttalandet fortfarande fanns i huvudminnet (=RAM) och Postgres inte behövde läsa dem från hårddisken.
"minne" syftar alltid på huvudminnet (RAM) som är inbyggt i datorn och direkt tillgängligt för processorn - till skillnad från "extern lagring".
Det finns flera presentationer om hur Postgres hanterar de delade buffertarna:
- http://de.slideshare.net/EnterpriseDB/insidepostgressharedmemory2015
- http://momjian.us/main/writings/pgsql/hw_performance/
- https://2ndquadrant.com/media/pdfs/talks/InsideBufferCache. pdf (mycket tekniska)
- http://raghavt.blogspot.de/2012/ 04/caching-in-postgresql.html