shared hit
v podstatě znamená, že hodnota již byla uložena do mezipaměti v hlavní paměti počítače a nebylo nutné ji číst z pevného disku.
Přístup k hlavní paměti (RAM) je velmi rychlejší než čtení hodnot z pevného disku. A to je důvod, proč je dotaz tím rychlejší, čím více má sdílených přístupů.
Ihned po spuštění Postgresu nejsou žádná data dostupná v hlavní paměti (RAM) a vše je potřeba načíst z pevného disku.
Zvažte tento krok z prováděcího plánu:
-> 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
Část "Buffery:sdílené čtení=2818" znamená, že z pevného disku se muselo načíst 2818 bloků (každý 8k) (a to trvalo 48ms - mám SSD). Těchto 2818 bloků bylo uloženo v mezipaměti ("sdílené vyrovnávací paměti "), takže až je příště bude potřeba, databáze je nebude muset číst (znovu) z (pomalého) pevného disku.
Když znovu spustím tento příkaz, plán se změní na:
-> 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
Což znamená, že těch 2818 bloků, které předchozí příkaz bylo stále v hlavní paměti (=RAM) a Postgres je nepotřeboval číst z pevného disku.
„paměť“ vždy odkazuje na hlavní paměť (RAM) zabudovanou v počítači a přímo přístupnou procesoru – na rozdíl od „externího úložiště“.
Existuje několik prezentací o tom, jak Postgres spravuje sdílené vyrovnávací paměti:
- http://de.slideshare.net/EnterpriseDB/insidepostgressharedmemory2015
- http://momjian.us/main/writings/pgsql/hw_performance/
- https://2ndquadrant.com/media/pdfs/talks/InsideBufferCache. pdf (velmi technické)
- http://raghavt.blogspot.de/2012/ 04/caching-in-postgresql.html