shared hit अनिवार्य रूप से इसका मतलब है कि मान पहले से ही कंप्यूटर की मुख्य मेमोरी में कैश किया जा चुका है और इसे हार्ड डिस्क से पढ़ना आवश्यक नहीं था।
मुख्य मेमोरी (RAM) तक पहुंच बहुत है हार्ड डिस्क से मान पढ़ने की तुलना में तेज़। और यही कारण है कि क्वेरी जितनी तेज़ होती है, उसके पास उतने ही अधिक शेयर हिट होते हैं।
Postgres शुरू करने के तुरंत बाद, कोई भी डेटा मुख्य मेमोरी (RAM) में उपलब्ध नहीं होता है और सब कुछ हार्ड डिस्क से पढ़ने की आवश्यकता होती है।
निष्पादन योजना के इस चरण पर विचार करें:
-> 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
भाग "बफ़र्स:साझा रीड =2818" का अर्थ है कि 2818 ब्लॉक (प्रत्येक 8k) को हार्ड डिस्क से पढ़ा जाना था (और इसमें 48ms लगे - मेरे पास एक एसएसडी है)। उन 2818 ब्लॉकों को कैश में संग्रहीत किया गया था ("साझा बफ़र्स ") ताकि अगली बार जरूरत पड़ने पर डेटाबेस को (धीमी) हार्ड डिस्क से उन्हें (फिर से) पढ़ने की जरूरत न पड़े।
जब मैं उस कथन को फिर से चलाता हूँ तो योजना बदल जाती है:
-> 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
जिसका अर्थ है कि वे 2818 ब्लॉक जो पिछले कथन अभी भी मुख्य मेमोरी (=RAM) में थे और पोस्टग्रेज़ को उन्हें हार्ड डिस्क से पढ़ने की आवश्यकता नहीं थी।
"मेमोरी" हमेशा कंप्यूटर में निर्मित मुख्य मेमोरी (रैम) को संदर्भित करता है और सीपीयू के लिए सीधे पहुंच योग्य होता है - "बाहरी भंडारण" के विपरीत।
Postgres साझा बफ़र्स को कैसे प्रबंधित करता है, इस पर कई प्रस्तुतियाँ हैं:
- http://de.slideshare.net/EnterpriseDB/insidepostgressharedmemory2015
- http://momjian.us/main/writings/pgsql/hw_performance/
- https://2ndquadrant.com/media/pdfs/talks/InsideBufferCache। पीडीएफ (बहुत तकनीकी)
- http://raghavt.blogspot.de/2012/ 04/caching-in-postgresql.html
