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

पिछली बार हमने 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 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 गैर-पंक्तिबद्ध पंक्ति संस्करण - 2 संस्करण तालिका में पाए गए जिन्हें हटाया नहीं जा सकता है,
• 1 मृत पंक्ति संस्करण अभी तक नहीं निकाले जा सके हैं - जिसमें 1 "मृत" भी शामिल है,
• सबसे पुराना xmin वर्तमान क्षितिज को दर्शाता है।

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

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

 | => 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) को एक विशेष सरणी में लिखा जाता है। सरणी सफाई प्रक्रिया की स्थानीय मेमोरी में स्थित है; इसके लिए रख- रखाव_वर्क_ मीम आकार का एक टुकड़ा आवंटित किया गया है। इस पैरामीटर के लिए डिफ़ॉल्ट मान 64 एमबी है। ध्यान दें कि यह मेमोरी तुरंत पूर्ण में आवंटित की गई है, और आवश्यकतानुसार नहीं। सच है, यदि टेबल छोटा है, तो टुकड़ा कम आवंटित किया जाता है।

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

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

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

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

इस तरह से:

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

बड़ी तालिकाओं पर, यह काफी समय ले सकता है और सिस्टम पर एक महत्वपूर्ण भार पैदा कर सकता है। बेशक, अनुरोधों को अवरुद्ध नहीं किया जाएगा, लेकिन "अतिरिक्त" I / O भी अप्रिय है।

प्रक्रिया को गति देने के लिए, यह या तो अधिक बार सफाई के लिए कॉल करने के लिए समझ में आता है (ताकि हर बार बहुत बड़ी संख्या में पंक्ति संस्करण साफ़ न हों), या अधिक मेमोरी आवंटित करें।

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

निगरानी

कैसे समझें कि सफाई एक पास में काम का सामना नहीं करती है?

हमने पहले तरीके को देखा है: आप VERBOSE के साथ VACUUM कमांड को कॉल कर सकते हैं। फिर कार्य के चरणों की जानकारी कंसोल पर प्रदर्शित की जाएगी।

दूसरे, 9.6 संस्करण के साथ शुरू, वहाँ एक दृश्य है pg_stat_progress_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(); 

हम सफाई करना शुरू करते हैं और जब यह काम करता है, तो हम कई बार 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);
• अनुक्रमणिका (index_vacuum_count) द्वारा पास की संख्या।

समग्र प्रगति 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 

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

के विश्लेषण

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

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

पूर्ण सफाई (वैक्यूम पूर्ण)

जैसा कि हमने देखा, पारंपरिक सफाई इंट्रा-पेज सफाई की तुलना में अधिक जगह को मुक्त करती है, लेकिन यहां तक ​​कि यह हमेशा समस्या को पूरी तरह से हल नहीं करता है।

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

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

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

यदि फ़ाइलों में उपयोगी जानकारी का हिस्सा एक उचित सीमा से नीचे आता है, तो व्यवस्थापक एक पूर्ण तालिका सफाई कर सकता है। उसी समय, तालिका और उसके सभी सूचक पूरी तरह से खरोंच से बनाए जाते हैं, और डेटा को यथासंभव कॉम्पैक्ट रूप से पैक किया जाता है (निश्चित रूप से, भराव पैरामीटर को ध्यान में रखते हुए)। जब पुनर्निर्माण होता है, तो 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 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) 

हम देखते हैं कि आकार नहीं बदला है: नियमित सफाई किसी भी तरह से फाइलों के आकार को कम नहीं कर सकती है। हालाँकि जानकारी का घनत्व लगभग 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) 

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

 => 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 भी है, जो दृश्यता मानचित्र में चिह्नित पृष्ठों को छोड़ देता है और अनुमानित संख्या दिखाता है।

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

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

इसी तरह की टीमें

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

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

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

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

जारी रखा जाए ।