बस आपको याद दिलाने के लिए, हमने पहले ही अलगाव से संबंधित मुद्दों पर चर्चा की, निम्न-स्तरीय डेटा संरचना के बारे में एक विषयांतर किया, और फिर पंक्ति संस्करणों की खोज की और देखा कि पंक्ति संस्करणों से डेटा स्नैपशॉट कैसे प्राप्त किए जाते हैं।

अब हम दो निकटता से जुड़ी समस्याओं पर आगे बढ़ेंगे: इन-पेज वैक्यूम और HOT अपडेट । दोनों तकनीकों को अनुकूलन के लिए संदर्भित किया जा सकता है; वे महत्वपूर्ण हैं, लेकिन वस्तुतः प्रलेखन में शामिल नहीं हैं।

नियमित अपडेट के दौरान इन-पेज वैक्यूम

किसी अद्यतन के लिए किसी पृष्ठ पर पहुँचते समय या पढ़ते समय, यदि PostgreSQL यह समझता है कि पृष्ठ अंतरिक्ष से बाहर चल रहा है, तो यह तेज़-इन-पेज वैक्यूम कर सकता है। यह दोनों मामलों में होता है:

1. इस पृष्ठ के पिछले अद्यतन को एक ही पृष्ठ में एक नया पंक्ति संस्करण आवंटित करने के लिए पर्याप्त स्थान नहीं मिला। पेज हेडर में ऐसी स्थिति को याद किया जाता है, और अगली बार पेज को वैक्यूम किया जाता है।
2. पृष्ठ fillfactor प्रतिशत से अधिक है। इस मामले में, वैक्यूम को अगले बिना बंद किए बिना तुरंत किया जाता है।

fillfactor एक भंडारण पैरामीटर है जिसे एक तालिका (और एक सूचकांक के लिए) के लिए परिभाषित किया जा सकता है। किसी पृष्ठ में एक नई पंक्ति का पोस्टग्रैसक्यूएस केवल तभी भरा जाता है जब पृष्ठ fillfactor प्रतिशत से कम हो। शेष स्थान नए tuples के लिए आरक्षित है जो अपडेट के परिणामस्वरूप बनाए गए हैं। तालिकाओं के लिए डिफ़ॉल्ट मान 100 है, अर्थात कोई स्थान आरक्षित नहीं है (और अनुक्रमित के लिए डिफ़ॉल्ट मान 90 है)।

इन-पेज वैक्यूम टुपल्स को हटाता है जो किसी भी स्नैपशॉट में दिखाई नहीं देते हैं (जो कि डेटाबेस के लेनदेन क्षितिज से परे हैं, जो पिछली बार चर्चा की गई थी), लेकिन यह एक टेबल पेज के भीतर सख्ती से करता है। निर्वात ट्यूपल्स को संकेत जारी नहीं किए जाते हैं क्योंकि उन्हें अनुक्रमित से संदर्भित किया जा सकता है, और एक सूचकांक दूसरे पृष्ठ पर है। इन-पेज वैक्यूम कभी भी एक टेबल पेज से आगे नहीं पहुंचता है, लेकिन बहुत जल्दी काम करता है।

उन्हीं कारणों से, मुक्त स्थान का नक्शा अपडेट नहीं होता है; यह आवेषण के बजाय अपडेट के लिए अतिरिक्त स्थान भी रखता है। दृश्यता मानचित्र अपडेट नहीं किया जाता है।

तथ्य यह है कि किसी पृष्ठ को रीड्स के दौरान वैक्यूम किया जा सकता है, इसका मतलब है कि एक सेलेक्ट क्वेरी पृष्ठों को बदलने का काम कर सकती है। यह पहले से चर्चा किए गए संकेत बिट्स के एक आस्थगित परिवर्तन के अलावा इस तरह का एक और मामला है।

आइए एक उदाहरण पर विचार करें कि यह कैसे काम करता है। आइए दोनों स्तंभों पर एक तालिका और अनुक्रमित बनाएं।

 => CREATE TABLE hot(id integer, s char(2000)) WITH (fillfactor = 75); => CREATE INDEX hot_id ON hot(id); => CREATE INDEX hot_s ON hot(s); 

यदि स्तंभ केवल लैटिन वर्णों को संग्रहीत करता है, तो प्रत्येक पंक्ति संस्करण 2004 बाइट्स और 24 हेडर के बाइट्स पर कब्जा कर लेगा। हमने fillfactor स्टोरेज पैरामीटर को 75% पर सेट किया है, जो तीन पंक्तियों के लिए पर्याप्त स्थान रखता है।

तालिका पृष्ठ की सामग्री को आसानी से देखने के लिए, चलिए आउटपुट में दो और फ़ील्ड जोड़कर पहले से ही परिचित फ़ंक्शन को फिर से बनाते हैं:

 => CREATE FUNCTION heap_page(relname text, pageno integer) RETURNS TABLE(ctid tid, state text, xmin text, xmax text, hhu text, hot text, t_ctid tid) AS $$ SELECT (pageno,lp)::text::tid AS ctid, CASE lp_flags WHEN 0 THEN 'unused' WHEN 1 THEN 'normal' WHEN 2 THEN 'redirect to '||lp_off WHEN 3 THEN 'dead' END AS state, t_xmin || CASE WHEN (t_infomask & 256) > 0 THEN ' (c)' WHEN (t_infomask & 512) > 0 THEN ' (a)' ELSE '' END AS xmin, t_xmax || CASE WHEN (t_infomask & 1024) > 0 THEN ' (c)' WHEN (t_infomask & 2048) > 0 THEN ' (a)' ELSE '' END AS xmax, CASE WHEN (t_infomask2 & 16384) > 0 THEN 't' END AS hhu, CASE WHEN (t_infomask2 & 32768) > 0 THEN 't' END AS hot, t_ctid FROM heap_page_items(get_raw_page(relname,pageno)) ORDER BY lp; $$ LANGUAGE SQL; 

इंडेक्स पेज को देखने के लिए एक फंक्शन भी बनाते हैं:

 => CREATE FUNCTION index_page(relname text, pageno integer) RETURNS TABLE(itemoffset smallint, ctid tid) AS $$ SELECT itemoffset, ctid FROM bt_page_items(relname,pageno); $$ LANGUAGE SQL; 

आइए देखें कि इन-पेज वैक्यूम कैसे काम करता है। ऐसा करने के लिए, हम एक पंक्ति सम्मिलित करते हैं और इसे कई बार बदलते हैं:

 => INSERT INTO hot VALUES (1, 'A'); => UPDATE hot SET s = 'B'; => UPDATE hot SET s = 'C'; => UPDATE hot SET s = 'D'; 

अब पृष्ठ में चार tuples हैं:

 => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+----------+-----+-----+-------- (0,1) | normal | 3979 (c) | 3980 (c) | | | (0,2) (0,2) | normal | 3980 (c) | 3981 (c) | | | (0,3) (0,3) | normal | 3981 (c) | 3982 | | | (0,4) (0,4) | normal | 3982 | 0 (a) | | | (0,4) (4 rows) 

जैसी कि उम्मीद थी, हम fillfactor सीमा से अधिक हो गए हैं। यह पृष्ठ आकार और upper मूल्यों के बीच के अंतर से स्पष्ट है: यह पृष्ठ आकार के 75% के बराबर सीमा से अधिक है, जो 6144 बाइट्स बनाता है।

 => SELECT lower, upper, pagesize FROM page_header(get_raw_page('hot',0)); 

  lower | upper | pagesize -------+-------+---------- 40 | 64 | 8192 (1 row) 

इसलिए, जब पृष्ठ अगली बार एक्सेस किया जाता है, तो इन-पेज वैक्यूम होना चाहिए। आइए इसकी जाँच करें।

 => UPDATE hot SET s = 'E'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+-------+-----+-----+-------- (0,1) | dead | | | | | (0,2) | dead | | | | | (0,3) | dead | | | | | (0,4) | normal | 3982 (c) | 3983 | | | (0,5) (0,5) | normal | 3983 | 0 (a) | | | (0,5) (5 rows) 

सभी मृत टुपल्स (0,1), (0,2) और (0,3) को खाली कर दिया जाता है; उसके बाद मुक्त स्थान में एक नया टपल (0.5) जोड़ा जाता है।

वैक्यूम करने से बचे टुपल्स को भौतिक रूप से पृष्ठ के उच्च पतों की ओर ले जाया जाता है ताकि सभी खाली स्थान एक निरंतर क्षेत्र द्वारा दर्शाए जाएं। बिंदुओं के मूल्यों को तदनुसार बदल दिया जाता है। इसके लिए धन्यवाद, एक पृष्ठ में मुक्त स्थान के विखंडन के साथ कोई समस्या नहीं आती है।

इंडेक्स पेज से रेफर किए जाने के बाद से वैक्यूम ट्यूपल्स को पॉइंटर्स जारी नहीं किए जा सकते। आइए hot_s इंडेक्स के पहले पृष्ठ पर नज़र डालें (क्योंकि पृष्ठ शून्य पर hot_s का कब्जा है):

 => SELECT * FROM index_page('hot_s',1); 

  itemoffset | ctid ------------+------- 1 | (0,1) 2 | (0,2) 3 | (0,3) 4 | (0,4) 5 | (0,5) (5 rows) 

हम अन्य सूचकांक में भी यही तस्वीर देखते हैं:

 => SELECT * FROM index_page('hot_id',1); 

  itemoffset | ctid ------------+------- 1 | (0,5) 2 | (0,4) 3 | (0,3) 4 | (0,2) 5 | (0,1) (5 rows) 

आप ध्यान दे सकते हैं कि पॉइंट टू टेबल रोयर्स एक रिवर्स ऑर्डर में यहाँ का अनुसरण करते हैं, लेकिन इससे कोई फर्क नहीं पड़ता क्योंकि सभी ट्यूपल्स का एक ही मूल्य है: id = 1। लेकिन पिछले सूचकांक में, संकेत s के मूल्यों द्वारा आदेश दिए गए हैं, और यह आवश्यक है।

इंडेक्स एक्सेस के साथ, PostgreSQL टपल आइडेंटीवर्स के रूप में (0,1), (0,2) या (0,3) प्राप्त कर सकता है। यह तब तालिका पृष्ठ से उपयुक्त पंक्ति संस्करण प्राप्त करने का प्रयास करेगा, लेकिन सूचक की "मृत" स्थिति के कारण, PostgreSQL यह पता लगाएगा कि ऐसा संस्करण अब मौजूद नहीं है और इसे अनदेखा कर देगा। (वास्तव में, एक बार पता चला है कि तालिका पंक्ति का संस्करण उपलब्ध नहीं है, PostgreSQL सूचकांक पृष्ठ में सूचक स्थिति को बदल देगा ताकि तालिका पृष्ठ का उपयोग न किया जा सके।)

यह आवश्यक है कि इन-पेज वैक्यूम केवल एक टेबल पेज के भीतर काम करता है और वैक्यूम इंडेक्स पेज नहीं करता है।

गर्म अपडेट

सूचकांक में सभी पंक्ति संस्करणों के संदर्भों को संग्रहीत करना क्यों अच्छा नहीं है?

सबसे पहले, पंक्ति के किसी भी परिवर्तन के लिए, तालिका के लिए बनाए गए सभी अनुक्रमों को अद्यतन करना होगा: एक बार एक नया संस्करण बन जाने के बाद, इसे संदर्भित करना होगा। और हमें इसे किसी भी मामले में करने की आवश्यकता है, भले ही फ़ील्ड को बदल दिया जाए जो अनुक्रमित नहीं हैं। यह स्पष्ट रूप से बहुत कुशल नहीं है।

दूसरा, अनुक्रमित ऐतिहासिक tuples के संदर्भ में जमा करते हैं, जिसे तब स्वयं के साथ tuples के साथ वैक्यूम करने की आवश्यकता होती है (हम थोड़ा बाद में चर्चा करेंगे कि यह कैसे किया जाता है)।

इसके अलावा, PostgreSQL में बी-ट्री में कार्यान्वयन की विशिष्टता है। यदि एक इंडेक्स पेज में नई पंक्ति डालने के लिए पर्याप्त स्थान नहीं है, तो पेज को दो में विभाजित किया गया है, और उनके बीच सभी डेटा वितरित किए गए हैं। इसे पेज का विभाजन कहा जाता है। हालाँकि, जब पंक्तियाँ हटा दी जाती हैं, तो दो अनुक्रमणिका पृष्ठ एक में विलय नहीं होते हैं। इस वजह से, यदि डेटा का एक महत्वपूर्ण हिस्सा हटा दिया जाता है, तो भी सूचकांक का आकार कम करने में विफल हो सकता है।

स्वाभाविक रूप से, एक टेबल पर जितने अधिक इंडेक्स बनाए जाते हैं, उतनी ही जटिलताएं सामने आती हैं।

हालाँकि, यदि किसी स्तंभ में ऐसा मान परिवर्तित किया जाता है जिसे बिल्कुल अनुक्रमित नहीं किया जाता है, तो अतिरिक्त बी-ट्री पंक्ति बनाने के लिए कोई मतलब नहीं होता है जिसमें कुंजी का समान मूल्य होता है। यह ठीक उसी तरह है कि अनुकूलन जिसे HOT अपडेट (हीप-ओनली ट्यूपल अपडेट) कहा जाता है, काम करता है।

इस अद्यतन के दौरान, इंडेक्स पेज में केवल एक पंक्ति होती है, जो तालिका पृष्ठ में पंक्ति के पहले संस्करण का संदर्भ देती है। और यह पहले से ही टेबल पेज के अंदर है, कि ट्यूपल्स की एक श्रृंखला आयोजित की जाती है:

• अद्यतित पंक्तियाँ जो श्रृंखला में हैं, हीप हॉट अपडेटेड बिट के साथ लेबल की गई हैं।
• सूचकांक से संदर्भित नहीं होने वाली पंक्तियों को हीप टपल बिट के साथ लेबल किया जाता है।
• हमेशा की तरह, पंक्ति संस्करणों को ctid फ़ील्ड के माध्यम से जोड़ा जाता है।

यदि इंडेक्स स्कैन के दौरान, PostgreSQL एक टेबल पेज को एक्सेस करता है और एक टपल पाता है जिसे हीप हॉट अपडेट के रूप में लेबल किया गया है, तो यह समझता है कि इसे बंद नहीं होना चाहिए, लेकिन इसमें प्रत्येक टपल को देखते हुए HOT चेन का पालन करना चाहिए। निश्चित रूप से, सभी टुपल्स को इस तरह से प्राप्त करने के लिए, क्लाइंट को उन्हें वापस करने से पहले दृश्यता की जांच की जाती है।

यह देखने के लिए कि एक HOT अपडेट कैसे काम करता है, आइए एक इंडेक्स हटाएं और टेबल को साफ़ करें।

 => DROP INDEX hot_s; => TRUNCATE TABLE hot; 

अब हम एक पंक्ति के इंसर्ट और अपडेट को फिर से करते हैं।

 => INSERT INTO hot VALUES (1, 'A'); => UPDATE hot SET s = 'B'; 

और यह हम तालिका पृष्ठ में देखते हैं:

 => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+-------+-----+-----+-------- (0,1) | normal | 3986 (c) | 3987 | t | | (0,2) (0,2) | normal | 3987 | 0 (a) | | t | (0,2) (2 rows) 

पृष्ठ में परिवर्तन की एक श्रृंखला है:

• हीप हॉट अपडेटेड ध्वज इंगित करता है कि ctid श्रृंखला का पालन किया जाना चाहिए।
• हीप ओनली टपल ध्वज दर्शाता है कि यह टपल इंडेक्स से संदर्भित नहीं है।

आगे के परिवर्तनों के साथ श्रृंखला बढ़ती जाएगी (पृष्ठ के भीतर):

 => UPDATE hot SET s = 'C'; => UPDATE hot SET s = 'D'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+----------+-----+-----+-------- (0,1) | normal | 3986 (c) | 3987 (c) | t | | (0,2) (0,2) | normal | 3987 (c) | 3988 (c) | t | t | (0,3) (0,3) | normal | 3988 (c) | 3989 | t | t | (0,4) (0,4) | normal | 3989 | 0 (a) | | t | (0,4) (4 rows) 

लेकिन सूचकांक में श्रृंखला के प्रमुख का केवल एक संदर्भ है:

 => SELECT * FROM index_page('hot_id',1); 

  itemoffset | ctid ------------+------- 1 | (0,1) (1 row) 

जोर देने के लिए, HOT अपडेट उस स्थिति में काम करते हैं जहाँ अद्यतन करने के लिए फ़ील्ड्स को बिल्कुल भी अनुक्रमित नहीं किया जाता है। अन्यथा, कुछ इंडेक्स में एक नई पंक्ति संस्करण के लिए सीधे संदर्भ होगा, और यह इस अनुकूलन की अवधारणा के साथ असंगत है।

अनुकूलन केवल एक पृष्ठ के भीतर काम करता है, और इसलिए, श्रृंखला के माध्यम से एक अतिरिक्त चलना अन्य पृष्ठों तक पहुंच की आवश्यकता नहीं है और प्रदर्शन को प्रभावित नहीं करता है।

HOT अपडेट के दौरान इन-पेज वैक्यूम

HOT अपडेट के दौरान वैक्यूम करना इन-पेज वैक्यूम का एक विशेष, लेकिन महत्वपूर्ण मामला है।

पहले की तरह, हम पहले ही fillfactor सीमा पार कर fillfactor , इसलिए अगले अद्यतन में एक इन-पेज वैक्यूम होना चाहिए। लेकिन इस बार पेज में अपडेट की एक श्रृंखला है। इस HOT श्रृंखला के प्रमुख को हमेशा वही रहना चाहिए जहाँ यह सूचकांक द्वारा संदर्भित होने के बाद से है, जबकि बाकी बिंदुओं को जारी किया जा सकता है: वे बाहर से कोई संदर्भ नहीं जानते हैं।

हेड पॉइंटर को न छूने के लिए, अप्रत्यक्ष संबोधन का उपयोग किया जाता है: इंडेक्स द्वारा संदर्भित पॉइंटर - (0,1) इस मामले में - "रीडायरेक्ट" स्थिति को प्राप्त करता है, जो उपयुक्त ट्यूपल पर रीडायरेक्ट करता है।

 => UPDATE hot SET s = 'E'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+---------------+----------+-------+-----+-----+-------- (0,1) | redirect to 4 | | | | | (0,2) | normal | 3990 | 0 (a) | | t | (0,2) (0,3) | unused | | | | | (0,4) | normal | 3989 (c) | 3990 | t | t | (0,2) (4 rows) 

ध्यान दें:

• ट्यूपल्स (0,1), (0,2) और (0,3) को वैक्यूम किया गया।
• हेड पॉइंटर (0,1) बना हुआ है, लेकिन इसने "रीडायरेक्ट" स्थिति हासिल कर ली है।
• नई पंक्ति संस्करण ओवरवोट (0,2) के बाद से निश्चित रूप से उस टपल के लिए कोई संदर्भ नहीं थे, और पॉइंटर जारी किया गया था ("अप्रयुक्त" स्थिति)।

चलो कई बार और अपडेट करते हैं:

 => UPDATE hot SET s = 'F'; => UPDATE hot SET s = 'G'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+---------------+----------+----------+-----+-----+-------- (0,1) | redirect to 4 | | | | | (0,2) | normal | 3990 (c) | 3991 (c) | t | t | (0,3) (0,3) | normal | 3991 (c) | 3992 | t | t | (0,5) (0,4) | normal | 3989 (c) | 3990 (c) | t | t | (0,2) (0,5) | normal | 3992 | 0 (a) | | t | (0,5) (5 rows) 

अगले अद्यतन में फिर से पेज वैक्यूमिंग का कारण बनता है:

 => UPDATE hot SET s = 'H'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+---------------+----------+-------+-----+-----+-------- (0,1) | redirect to 5 | | | | | (0,2) | normal | 3993 | 0 (a) | | t | (0,2) (0,3) | unused | | | | | (0,4) | unused | | | | | (0,5) | normal | 3992 (c) | 3993 | t | t | (0,2) (5 rows) 

फिर से, कुछ टुपल्स को वैक्यूम किया जाता है, और सूचक को चेन के सिर पर ले जाया जाता है।

निष्कर्ष: यदि स्तंभों को अनुक्रमित नहीं किया जाता है जो अक्सर अद्यतन किए जाते हैं, तो यह अद्यतन के लिए कुछ पृष्ठ स्थान आरक्षित करने के लिए fillfactor पैरामीटर को कम करने के लिए समझ में आ सकता है। हालांकि, हमें इस बात का ध्यान रखना चाहिए कि कम से कम fillfactor , अधिक खाली स्थान एक पृष्ठ में छोड़ दिया जाता है, इसलिए तालिका का भौतिक आकार बढ़ता है।

एक गर्म श्रृंखला का टूटना

यदि पृष्ठ को नया टपल आवंटित करने के लिए खाली स्थान का अभाव है, तो श्रृंखला टूट जाएगी। और हमें इंडेक्स से एक अलग पृष्ठ में स्थित पंक्ति संस्करण के लिए एक अलग संदर्भ बनाना होगा।

इस स्थिति को पुन: उत्पन्न करने के लिए, आइए एक समवर्ती लेनदेन शुरू करें और इसमें डेटा स्नैपशॉट बनाएं।

 | => BEGIN ISOLATION LEVEL REPEATABLE READ; | => SELECT count(*) FROM hot; 

 | count | ------- | 1 | (1 row) 

स्नैपशॉट पृष्ठ में टुपल्स को दूर करने की अनुमति नहीं देगा। अब पहले सत्र में एक अपडेट करते हैं:

 => UPDATE hot SET s = 'I'; => UPDATE hot SET s = 'J'; => UPDATE hot SET s = 'K'; => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+---------------+----------+----------+-----+-----+-------- (0,1) | redirect to 2 | | | | | (0,2) | normal | 3993 (c) | 3994 (c) | t | t | (0,3) (0,3) | normal | 3994 (c) | 3995 (c) | t | t | (0,4) (0,4) | normal | 3995 (c) | 3996 | t | t | (0,5) (0,5) | normal | 3996 | 0 (a) | | t | (0,5) (5 rows) 

अगले अद्यतन में, पृष्ठ में पर्याप्त स्थान नहीं होगा, लेकिन इन-पेज वैक्यूम कुछ भी खाली करने में असमर्थ होगा:

 => UPDATE hot SET s = 'L'; 

 | => COMMIT; -- snapshot no longer needed 

 => SELECT * FROM heap_page('hot',0); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+---------------+----------+----------+-----+-----+-------- (0,1) | redirect to 2 | | | | | (0,2) | normal | 3993 (c) | 3994 (c) | t | t | (0,3) (0,3) | normal | 3994 (c) | 3995 (c) | t | t | (0,4) (0,4) | normal | 3995 (c) | 3996 (c) | t | t | (0,5) (0,5) | normal | 3996 (c) | 3997 | | t | (1,1) (5 rows) 

टपल (0,5) में, (1,1) का संदर्भ है, जो पेज 1 में है।

 => SELECT * FROM heap_page('hot',1); 

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+------+-------+-----+-----+-------- (1,1) | normal | 3997 | 0 (a) | | | (1,1) (1 row) 

अब सूचकांक में दो पंक्तियाँ हैं, जिनमें से प्रत्येक इसकी गर्म श्रृंखला की शुरुआत की ओर इशारा करती है:

 => SELECT * FROM index_page('hot_id',1); 

  itemoffset | ctid ------------+------- 1 | (1,1) 2 | (0,1) (2 rows) 

दुर्भाग्य से, प्रलेखन में वस्तुतः इन-पेज वैक्यूम और HOT अपडेट्स की जानकारी का अभाव होता है, और आपको स्रोत कोड में उत्तर तलाशने चाहिए। मैं आपको README.HOT से शुरू करने की सलाह देता हूं ।

पर पढ़ें ।