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

पिछली बार हमने HOT अपडेट और इन-पेज वैक्यूमिंग के बारे में बात की थी, और आज हम एक प्रसिद्ध वैक्यूम वल्गरिस पर आगे बढ़ेंगे। वास्तव में, इसके बारे में इतना पहले ही लिखा जा चुका है कि मैं शायद ही कुछ नया जोड़ पाऊं, लेकिन एक पूरी तस्वीर की सुंदरता के लिए बलिदान की आवश्यकता होती है। इसलिए धैर्य बनाए रखें।

वैक्यूम

वैक्यूम क्या करता है?

इन-पेज वैक्यूम तेजी से काम करता है, लेकिन अंतरिक्ष के केवल हिस्से को मुक्त करता है। यह एक टेबल पेज के भीतर काम करता है और इंडेक्स को नहीं छूता है।

बेसिक, "सामान्य" वैक्यूम VACUUM कमांड का उपयोग करके किया जाता है, और हम इसे "वैक्यूम" (एक अलग चर्चा के लिए "ऑटोवैक्यूम" छोड़कर) कहेंगे।

तो, वैक्यूम पूरी तालिका को संसाधित करता है। यह न केवल मृत टुपल्स को दूर करता है, बल्कि सभी इंडेक्स से भी उन्हें संदर्भित करता है।

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

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

मुक्त स्थान का नक्शा भी पृष्ठों में अतिरिक्त खाली स्थान को प्रतिबिंबित करने की प्रक्रिया में अद्यतन हो जाता है।

हमेशा की तरह, आइए एक तालिका बनाएँ:

=> CREATE TABLE vac( id serial, s char(100) ) WITH (autovacuum_enabled = off); => CREATE INDEX vac_s ON vac(s); => INSERT INTO vac(s) VALUES ('A'); => UPDATE vac SET s = 'B'; => UPDATE vac SET s = 'C'; 

हम ऑटोवैक्यूम प्रक्रिया को बंद करने के लिए ऑटोवैक्यूम_ जेनरेटेड पैरामीटर का उपयोग करते हैं। हम अगली बार इस पर चर्चा करेंगे, और अब यह हमारे प्रयोगों के लिए महत्वपूर्ण है कि हम मैन्युअल रूप से वैक्यूमिंग को नियंत्रित करते हैं।

तालिका में अब तीन ट्यूपल हैं, जिनमें से प्रत्येक को सूचकांक से संदर्भित किया गया है:

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

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+----------+-----+-----+-------- (0,1) | normal | 4000 (c) | 4001 (c) | | | (0,2) (0,2) | normal | 4001 (c) | 4002 | | | (0,3) (0,3) | normal | 4002 | 0 (a) | | | (0,3) (3 rows) 

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

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

वैक्यूम करने के बाद, मृत टुपल्स को वैक्यूम किया जाता है, और केवल एक, जीवित, ट्यूपल रहता है। और केवल एक संदर्भ सूचकांक में रहता है:

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

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+-------+-----+-----+-------- (0,1) | unused | | | | | (0,2) | unused | | | | | (0,3) | normal | 4002 (c) | 0 (a) | | | (0,3) (3 rows) 

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

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

ध्यान दें कि पहले दो बिंदुओं ने "मृत" के बजाय "अप्रयुक्त" स्थिति का अधिग्रहण किया, जिसे वे इन-पेज वैक्यूम के साथ अधिग्रहित करेंगे।

एक बार फिर लेन-देन क्षितिज के बारे में

PostgreSQL कैसे करता है कि किस ट्यूपल्स को मृत माना जा सकता है? डेटा स्नैपशॉट पर चर्चा करते समय हमने पहले ही लेन-देन क्षितिज की अवधारणा को छू लिया था, लेकिन यह इस तरह के एक महत्वपूर्ण मामले को दोहराता नहीं है।

चलो पिछले प्रयोग को फिर से शुरू करते हैं।

 => TRUNCATE vac; => INSERT INTO vac(s) VALUES ('A'); => UPDATE vac SET s = 'B'; 

लेकिन एक बार फिर से पंक्ति को अपडेट करने से पहले, एक और लेनदेन शुरू करें (लेकिन अंत नहीं)। इस उदाहरण में, यह रीड कमिटेड स्तर का उपयोग करेगा, लेकिन इसे एक सच्चा (आभासी नहीं) लेनदेन नंबर प्राप्त करना होगा। उदाहरण के लिए, लेन-देन बदल सकता है और यहां तक ​​कि किसी भी तालिका में कुछ पंक्तियों को लॉक कर सकता है, अनिवार्य नहीं:

 | => BEGIN; | => SELECT s FROM t FOR UPDATE; 

 | s | ----- | FOO | BAR | (2 rows) 

 => UPDATE vac SET s = 'C'; 

तालिका में तीन पंक्तियाँ हैं और सूचकांक में तीन संदर्भ हैं। वैक्यूम करने के बाद क्या होगा?

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

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+----------+-----+-----+-------- (0,1) | unused | | | | | (0,2) | normal | 4005 (c) | 4007 (c) | | | (0,3) (0,3) | normal | 4007 (c) | 0 (a) | | | (0,3) (3 rows) 

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

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

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

 | => SELECT backend_xmin FROM pg_stat_activity WHERE pid = pg_backend_pid(); 

 | backend_xmin | -------------- | 4006 | (1 row) 

हम VACUUM को रिपोर्ट करने के लिए कह सकते हैं कि क्या हो रहा है:

 => VACUUM VERBOSE vac; 

 INFO: vacuuming "public.vac" INFO: index "vac_s" now contains 2 row versions in 2 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. INFO: "vac": found 0 removable, 2 nonremovable row versions in 1 out of 1 pages DETAIL: 1 dead row versions cannot be removed yet, oldest xmin: 4006 There were 1 unused item pointers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. VACUUM 

ध्यान दें:

• 2 nonremovable row versions - दो ट्यूपल जो डिलीट नहीं किए जा सकते हैं वे टेबल में पाए जाते हैं।
• 1 dead row versions cannot be removed yet - उनमें से एक मृत है।
• oldest xmin वर्तमान क्षितिज को दर्शाता है।

आइए निष्कर्ष को दोहराते हैं: यदि किसी डेटाबेस में लंबे समय तक लेनदेन होता है (पूरा नहीं हुआ है या वास्तव में लंबा प्रदर्शन किया जा रहा है), तो यह टेबल ब्लोट में प्रवेश कर सकता है, भले ही कितनी बार वैक्यूमिंग हो। इसलिए, OLTP- और OLAP- प्रकार वर्कलोड एक PostgreSQL डेटाबेस में खराब रूप से सह-अस्तित्व में है: घंटों तक चलने वाली रिपोर्ट अद्यतन तालिकाओं को विधिवत वैक्यूम नहीं होने देगी। रिपोर्टिंग उद्देश्यों के लिए एक अलग प्रतिकृति का निर्माण इस का एक संभावित समाधान हो सकता है।

एक खुले लेनदेन के पूरा होने के बाद, क्षितिज चलता है, और स्थिति ठीक हो जाती है:

 | => COMMIT; 

 => VACUUM VERBOSE vac; 

 INFO: vacuuming "public.vac" INFO: scanned index "vac_s" to remove 1 row versions DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s INFO: "vac": removed 1 row versions in 1 pages DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s INFO: index "vac_s" now contains 1 row versions in 2 pages DETAIL: 1 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. INFO: "vac": found 1 removable, 1 nonremovable row versions in 1 out of 1 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 4008 There were 1 unused item pointers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. VACUUM 

अब केवल नवीनतम, लाइव, पंक्ति का संस्करण पृष्ठ में बचा है:

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

  ctid | state | xmin | xmax | hhu | hot | t_ctid -------+--------+----------+-------+-----+-----+-------- (0,1) | unused | | | | | (0,2) | unused | | | | | (0,3) | normal | 4007 (c) | 0 (a) | | | (0,3) (3 rows) 

सूचकांक में भी केवल एक पंक्ति है:

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

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

अंदर क्या होता है?

वैक्यूमिंग को एक ही समय में टेबल और इंडेक्स को संसाधित करना चाहिए और ऐसा करना चाहिए ताकि अन्य प्रक्रियाओं को लॉक न करें। यह कैसे कर सकता है?

सभी स्कैनिंग हीप चरण (दृश्यता मानचित्र को ध्यान में रखते हुए, जैसा कि पहले ही उल्लेख किया गया है) से शुरू होता है। पढ़े गए पृष्ठों में, मृत टुपल्स का पता लगाया जाता है, और उनके tid s को एक विशेष सरणी के नीचे लिखा जाता है। सरणी को वैक्यूम प्रक्रिया की स्थानीय मेमोरी में संग्रहीत किया जाता है, जहां इसके लिए मेंटेनेंस_वर्क_ मीम बाइट्स आवंटित की जाती हैं। इस पैरामीटर का डिफ़ॉल्ट मान 64 एमबी है। ध्यान दें कि मेमोरी की पूरी मात्रा एक बार में आवंटित की जाती है, बजाय इसके कि जरूरत पड़ने पर। हालाँकि, यदि मेज बड़ी नहीं है, तो थोड़ी मात्रा में मेमोरी आवंटित की जाती है।

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

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

उसके बाद, वैक्यूमिंग हीप चरण शुरू होता है। उपयुक्त पृष्ठों को पढ़ने के लिए तालिका को फिर से स्कैन किया जाता है, उन्हें याद किए गए टुपल्स को वैक्यूम करके पॉइंटर्स जारी करते हैं। हम ऐसा कर सकते हैं क्योंकि अब सूचकांक से कोई संदर्भ नहीं हैं।

यदि तालिका पहले चक्र के दौरान पूरी तरह से नहीं पढ़ी गई थी, तो सरणी को मंजूरी दे दी गई है और जहां हम पहुंचे थे वहां से सब कुछ दोहराया गया है।

संक्षेप में:

• तालिका को हमेशा दो बार स्कैन किया जाता है।
• यदि वैक्यूमिंग इतने सारे ट्यूपल्स को हटा देता है कि वे सभी आकार के रखरखाव_वर्क_म की स्मृति में फिट नहीं होते हैं, तो सभी इंडेक्सों को आवश्यकतानुसार कई बार स्कैन किया जाएगा।

बड़ी तालिकाओं के लिए, इसके लिए बहुत समय की आवश्यकता होती है और महत्वपूर्ण कार्यभार जोड़ सकते हैं। बेशक, प्रश्नों को लॉक नहीं किया जाएगा, लेकिन अतिरिक्त इनपुट / आउटपुट निश्चित रूप से अवांछनीय है।

प्रक्रिया को गति देने के लिए, यह या तो VACUUM को अधिक बार कॉल करने के लिए समझ में आता है (ताकि हर बार बहुत अधिक ट्यूपल्स को वैक्यूम न किया जाए) या अधिक मेमोरी आवंटित करें।

कोष्ठक में नोट करने के लिए, 11 संस्करण से शुरू, PostgreSQL सूचकांक स्कैन को छोड़ सकता है जब तक कि एक सम्मोहक की आवश्यकता नहीं होती है। इससे बड़ी तालिकाओं के मालिकों के लिए जीवन आसान हो जाता है जहाँ पंक्तियाँ केवल जोड़ी जाती हैं (लेकिन बदली नहीं जाती)।

निगरानी

हम यह कैसे पता लगा सकते हैं कि VACUUM एक चक्र में अपना काम नहीं कर सकता है?

हमने पहले से ही पहला तरीका देखा है: VERBOSE विकल्प के साथ VACUUM कमांड को कॉल करने के लिए। इस मामले में, प्रक्रिया के चरणों के बारे में जानकारी कंसोल पर आउटपुट होगी।

दूसरा, संस्करण 9.6 से शुरू होकर, pg_stat_progress_vacuum दृश्य उपलब्ध है, जो सभी आवश्यक जानकारी भी प्रदान करता है।

(तीसरा तरीका भी उपलब्ध है: सूचना को संदेश लॉग में भेजने के लिए, लेकिन यह केवल ऑटोकैसम के लिए काम करता है, जिस पर अगली बार चर्चा की जाएगी।)

चलो वैक्यूम प्रक्रिया के लिए बहुत लंबे समय तक चलने के लिए, तालिका में काफी कुछ पंक्तियाँ डालें, और उन सभी को अपडेट करें, ताकि VACUUM को करने के लिए सामान मिल सके।

 => TRUNCATE vac; => INSERT INTO vac(s) SELECT 'A' FROM generate_series(1,500000); => UPDATE vac SET s = 'B'; 

आइए पहचानकर्ताओं की सरणी के लिए आवंटित स्मृति आकार को कम करें:

 => ALTER SYSTEM SET maintenance_work_mem = '1MB'; => SELECT pg_reload_conf(); 

चलिए VACUUM शुरू करते हैं और जब यह काम कर रहा है, तो कई बार pg_stat_progress_vacuum दृश्य पर pg_stat_progress_vacuum :

 => VACUUM VERBOSE vac; 

 | => SELECT * FROM pg_stat_progress_vacuum \gx 

 | -[ RECORD 1 ]------+------------------ | pid | 6715 | datid | 41493 | datname | test | relid | 57383 | phase | vacuuming indexes | heap_blks_total | 16667 | heap_blks_scanned | 2908 | heap_blks_vacuumed | 0 | index_vacuum_count | 0 | max_dead_tuples | 174762 | num_dead_tuples | 174480 

 | => SELECT * FROM pg_stat_progress_vacuum \gx 

 | -[ RECORD 1 ]------+------------------ | pid | 6715 | datid | 41493 | datname | test | relid | 57383 | phase | vacuuming indexes | heap_blks_total | 16667 | heap_blks_scanned | 5816 | heap_blks_vacuumed | 2907 | index_vacuum_count | 1 | max_dead_tuples | 174762 | num_dead_tuples | 174480 

यहाँ हम देख सकते हैं, विशेष रूप से:

• वर्तमान चरण का नाम - हमने तीन मुख्य चरणों पर चर्चा की, लेकिन उनमें से सामान्य रूप से अधिक हैं।
• तालिका पृष्ठों की कुल संख्या ( heap_blks_total )।
• स्कैन किए गए पृष्ठों की संख्या ( heap_blks_scanned )।
• पहले से ही heap_blks_vacuumed पृष्ठों की संख्या ( heap_blks_vacuumed )।
• सूचकांक वैक्यूम चक्र ( index_vacuum_count ) की संख्या।

सामान्य प्रगति heap_blks_vacuumed के heap_blks_vacuumed के अनुपात से निर्धारित heap_blks_total , लेकिन हमें यह ध्यान रखना चाहिए कि अनुक्रमणिका को स्कैन करने के कारण यह मूल्य सुगमता के बजाय बड़े वेतन वृद्धि में बदल जाता है। हालांकि, मुख्य ध्यान वैक्यूम चक्र की संख्या को दिया जाना चाहिए: 1 से अधिक संख्या का मतलब है कि आवंटित की गई मेमोरी एक चक्र में वैक्यूमिंग को पूरा करने के लिए पर्याप्त नहीं थी।

VACUUM VERBOSE कमांड का आउटपुट, जो उस समय तक पूरा हो चुका है, सामान्य चित्र दिखाएगा:

 INFO: vacuuming "public.vac" 

 INFO: scanned index "vac_s" to remove 174480 row versions DETAIL: CPU: user: 0.50 s, system: 0.07 s, elapsed: 1.36 s INFO: "vac": removed 174480 row versions in 2908 pages DETAIL: CPU: user: 0.02 s, system: 0.02 s, elapsed: 0.13 s 

 INFO: scanned index "vac_s" to remove 174480 row versions DETAIL: CPU: user: 0.26 s, system: 0.07 s, elapsed: 0.81 s INFO: "vac": removed 174480 row versions in 2908 pages DETAIL: CPU: user: 0.01 s, system: 0.02 s, elapsed: 0.10 s 

 INFO: scanned index "vac_s" to remove 151040 row versions DETAIL: CPU: user: 0.13 s, system: 0.04 s, elapsed: 0.47 s INFO: "vac": removed 151040 row versions in 2518 pages DETAIL: CPU: user: 0.01 s, system: 0.02 s, elapsed: 0.08 s 

 INFO: index "vac_s" now contains 500000 row versions in 17821 pages DETAIL: 500000 index row versions were removed. 8778 index pages have been deleted, 0 are currently reusable. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. INFO: "vac": found 500000 removable, 500000 nonremovable row versions in 16667 out of 16667 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 4011 There were 0 unused item pointers. 0 pages are entirely empty. CPU: user: 1.10 s, system: 0.37 s, elapsed: 3.71 s. VACUUM 

हम यहां देख सकते हैं कि इंडेक्स के ऊपर तीन चक्र किए गए थे, और प्रत्येक चक्र में, 174480 पॉइंट टू डेड ट्यूपल्स को वैक्यूम किया गया था। वास्तव में यह संख्या क्यों है? एक tid पर 6 बाइट्स होती हैं, और 1024 * 1024/6 = 174762, जो कि वह संख्या है जो हम pg_stat_progress_vacuum.max_dead_tuples में देखते हैं। वास्तव में, थोड़ा कम इस्तेमाल किया जा सकता है: यह सुनिश्चित करता है कि जब एक अगला पृष्ठ पढ़ा जाता है, तो मृत टुपल्स के सभी संकेत निश्चित रूप से स्मृति में फिट होंगे।

विश्लेषण

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

लेकिन जैसा कि हम बाद में देखेंगे, ऑटोवैक्यूम और स्वचालित विश्लेषण एक प्रक्रिया में किए जाते हैं और एक समान तरीके से नियंत्रित होते हैं।

रिक्त स्थान

जैसा कि ऊपर उल्लेख किया गया है, वैक्यूम इन-पेज वैक्यूम की तुलना में अधिक स्थान मुक्त करता है, लेकिन फिर भी यह पूरी तरह से समस्या का समाधान नहीं करता है।

यदि कुछ कारणों से एक टेबल या इंडेक्स का आकार बहुत बढ़ गया है, तो VACUUM मौजूदा पृष्ठों के अंदर स्थान खाली कर देगा: "छेद" वहां होगा, जो तब नए ट्यूपल्स के सम्मिलन के लिए उपयोग किया जाएगा। लेकिन पृष्ठों की संख्या में परिवर्तन नहीं होगा, और इसलिए, ऑपरेटिंग सिस्टम के दृष्टिकोण से, फाइलें वैक्यूम से पहले ठीक उसी स्थान पर कब्जा कर लेंगी। और यह अच्छा नहीं है क्योंकि:

• तालिका (या सूचकांक) का पूरा स्कैन धीमा हो जाता है।
• एक बड़े बफ़र कैश की आवश्यकता हो सकती है (क्योंकि यह ऐसे पृष्ठ हैं जो वहां संग्रहीत हैं और उपयोगी जानकारी का घनत्व कम हो जाता है)।
• इंडेक्स ट्री में एक अतिरिक्त स्तर हो सकता है, जो इंडेक्स एक्सेस को धीमा कर देगा।
• फ़ाइलें डिस्क पर और बैकअप प्रतियों में अतिरिक्त स्थान लेती हैं।

(एकमात्र अपवाद पूरी तरह से वैक्यूम किए गए पृष्ठ हैं, जो फ़ाइल के अंत में स्थित है। ये पृष्ठ फ़ाइल से ट्रिम किए गए हैं और ऑपरेटिंग सिस्टम पर वापस आ गए हैं।)

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

इसे स्पष्ट करने के लिए, आइए फिर से तालिका में एक निश्चित संख्या में पंक्तियाँ डालें:

 => TRUNCATE vac; => INSERT INTO vac(s) SELECT 'A' FROM generate_series(1,500000); 

हम सूचना घनत्व का अनुमान कैसे लगा सकते हैं? ऐसा करने के लिए, किसी विशेष एक्सटेंशन का उपयोग करना सुविधाजनक है:

 => CREATE EXTENSION pgstattuple; => SELECT * FROM pgstattuple('vac') \gx 

 -[ RECORD 1 ]------+--------- table_len | 68272128 tuple_count | 500000 tuple_len | 64500000 tuple_percent | 94.47 dead_tuple_count | 0 dead_tuple_len | 0 dead_tuple_percent | 0 free_space | 38776 free_percent | 0.06 

फ़ंक्शन पूरी तालिका को पढ़ता है और आंकड़े दिखाता है: कौन सा डेटा फाइलों में कितनी जगह रखता है। हमारी रुचि की मुख्य जानकारी अब tuple_percent फ़ील्ड है: उपयोगी डेटा का प्रतिशत। यह एक पृष्ठ के अंदर अपरिहार्य सूचना के कारण 100 से कम है, लेकिन अभी भी बहुत अधिक है।

सूचकांक के लिए, अलग-अलग जानकारी आउटपुट है, लेकिन avg_leaf_density क्षेत्र का एक ही अर्थ है: उपयोगी जानकारी का प्रतिशत (पत्ती पृष्ठों में)।

 => SELECT * FROM pgstatindex('vac_s') \gx 

 -[ RECORD 1 ]------+--------- version | 3 tree_level | 3 index_size | 72802304 root_block_no | 2722 internal_pages | 241 leaf_pages | 8645 empty_pages | 0 deleted_pages | 0 avg_leaf_density | 83.77 leaf_fragmentation | 64.25 

और ये टेबल और इंडेक्स के आकार हैं:

 => SELECT pg_size_pretty(pg_table_size('vac')) table_size, pg_size_pretty(pg_indexes_size('vac')) index_size; 

  table_size | index_size ------------+------------ 65 MB | 69 MB (1 row) 

अब 90% सभी पंक्तियों को हटा देते हैं। हम हटाने के लिए पंक्तियों का एक यादृच्छिक विकल्प करते हैं, ताकि प्रत्येक पृष्ठ में कम से कम एक पंक्ति के बने रहने की अत्यधिक संभावना हो:

 => DELETE FROM vac WHERE random() < 0.9; 

 DELETE 450189 

VACUUM के बाद वस्तुओं का आकार क्या होगा?

 => VACUUM vac; => SELECT pg_size_pretty(pg_table_size('vac')) table_size, pg_size_pretty(pg_indexes_size('vac')) index_size; 

  table_size | index_size ------------+------------ 65 MB | 69 MB (1 row) 

हम देख सकते हैं कि आकार नहीं बदला: VACUUM कोई भी तरीका फ़ाइलों के आकार को कम नहीं कर सकता है। और यद्यपि यह सूचना घनत्व लगभग 10 गुना कम हो गया है:

 => SELECT vac.tuple_percent, vac_s.avg_leaf_density FROM pgstattuple('vac') vac, pgstatindex('vac_s') vac_s; 

  tuple_percent | avg_leaf_density ---------------+------------------ 9.41 | 9.73 (1 row) 

अब देखते हैं कि VACUUM FULL के बाद हमें क्या मिलता है। अब टेबल और इंडेक्स निम्नलिखित फाइलों का उपयोग करते हैं:

 => SELECT pg_relation_filepath('vac'), pg_relation_filepath('vac_s'); 

  pg_relation_filepath | pg_relation_filepath ----------------------+---------------------- base/41493/57392 | base/41493/57393 (1 row) 

 => VACUUM FULL vac; => SELECT pg_relation_filepath('vac'), pg_relation_filepath('vac_s'); 

  pg_relation_filepath | pg_relation_filepath ----------------------+---------------------- base/41493/57404 | base/41493/57407 (1 row) 

फ़ाइलों को अब नए के साथ बदल दिया गया है। तालिका और अनुक्रमित के आकार में काफी कमी आई, जबकि सूचना घनत्व तदनुसार बढ़ा:

 => SELECT pg_size_pretty(pg_table_size('vac')) table_size, pg_size_pretty(pg_indexes_size('vac')) index_size; 

  table_size | index_size ------------+------------ 6648 kB | 6480 kB (1 row) 

 => SELECT vac.tuple_percent, vac_s.avg_leaf_density FROM pgstattuple('vac') vac, pgstatindex('vac_s') vac_s; 

  tuple_percent | avg_leaf_density ---------------+------------------ 94.39 | 91.08 (1 row) 

ध्यान दें कि सूचकांक में सूचना घनत्व मूल एक से भी अधिक है। मौजूदा सूचकांक पंक्ति में डेटा डालने की तुलना में उपलब्ध डेटा से एक इंडेक्स (बी-ट्री) का पुनर्निर्माण करना अधिक फायदेमंद है।

Pgstattuple एक्सटेंशन के कार्य जिनका हमने उपयोग किया था, पूरी तालिका को पढ़ा। लेकिन यह असुविधाजनक है यदि तालिका बड़ी है, तो विस्तार में pgstattuple_approx फ़ंक्शन है, जो दृश्यता मानचित्र में चिह्नित पृष्ठों को छोड़ देता है और अनुमानित आंकड़े दिखाता है।

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

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

इसी तरह के आदेश

कुछ कमांड्स हैं जो पूरी तरह से टेबल और इंडेक्स का पुनर्निर्माण करती हैं और इसलिए VACUUM FULL से मिलती जुलती हैं। वे सभी तालिका के साथ किसी भी कार्य को पूरी तरह से रोकते हैं, वे सभी पुरानी डेटा फ़ाइलों को हटाते हैं और नए बनाते हैं।

CLUSTER कमांड सभी VACUUM FULL के समान है, लेकिन यह उपलब्ध इंडेक्स में से एक के अनुसार शारीरिक रूप से ट्यूपल्स का भी आदेश देता है। यह कुछ मामलों में इंडेक्स एक्सेस का अधिक कुशलता से उपयोग करने के लिए प्लानर को सक्षम बनाता है। लेकिन हमें यह ध्यान रखना चाहिए कि क्लस्टरिंग को बनाए नहीं रखा जाता है: टेबल के बाद के बदलावों के साथ टुपल्स का भौतिक क्रम टूट जाएगा।

REINDEX कमांड टेबल पर एक अलग सूचकांक का पुनर्निर्माण करता है। VACUUM FULL और CLUSTER वास्तव में अनुक्रमों के पुनर्निर्माण के लिए इस कमांड का उपयोग करते हैं।

TRUNCATE कमांड का तर्क DELETE के समान है - यह सभी तालिका पंक्तियों को हटा देता है। लेकिन DELETE, जैसा कि पहले ही उल्लेख किया गया है, केवल हटाए गए के रूप में tuples को चिह्नित करता है, और इसके लिए आगे वैक्यूमिंग की आवश्यकता होती है। और TRUNCATE सिर्फ एक नई, साफ फ़ाइल बनाता है। एक नियम के रूप में, यह तेजी से काम करता है, लेकिन हमें यह ध्यान रखना चाहिए कि TRUNCATE लेनदेन के अंत तक तालिका के साथ किसी भी काम को रोक देगा।

पर पढ़ें ।