shared hit
pada dasarnya berarti nilai telah di-cache di memori utama komputer dan tidak perlu membaca ini dari hard disk.
Mengakses memori utama (RAM) banyak lebih cepat daripada membaca nilai dari hard disk. Dan itulah mengapa kueri lebih cepat, semakin banyak klik berbagi yang dimilikinya.
Segera setelah memulai Postgres, tidak ada data yang tersedia di memori utama (RAM) dan semuanya perlu dibaca dari hard disk.
Pertimbangkan langkah ini dari rencana eksekusi:
-> 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
Bagian "Buffer:shared read=2818" berarti 2818 blok (masing-masing 8k) harus dibaca dari hard disk (dan itu membutuhkan waktu 48ms - saya memiliki SSD). 2818 blok tersebut disimpan dalam cache ("buffer bersama ") sehingga pada saat dibutuhkan database tidak perlu membacanya (lagi) dari hard disk (lambat).
Ketika saya menjalankan kembali pernyataan itu, rencananya berubah menjadi:
-> 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
Artinya 2818 blok yang pernyataan sebelumnya masih berada di memori utama (=RAM) dan Postgres tidak perlu membacanya dari hard disk.
"memori" selalu mengacu pada memori utama (RAM) yang terpasang di komputer dan dapat diakses langsung ke CPU - sebagai lawan dari "penyimpanan eksternal".
Ada beberapa presentasi tentang bagaimana Postgres mengelola buffer bersama:
- http://de.slideshare.net/EnterpriseDB/insidepostgressharedmemory2015
- http://momjian.us/main/writings/pgsql/hw_performance/
- https://2ndquadrant.com/media/pdfs/talks/InsideBufferCache. pdf (sangat teknis)
- http://raghavt.blogspot.de/2012/ 04/caching-in-postgresql.html