मीटअप के बाद "PostgreSQL 11 नई सुविधाएँ"

आज हम PostgreSQL 11 की सबसे महत्वपूर्ण विशेषताओं के बारे में बात करेंगे। केवल उनके बारे में क्यों - क्योंकि हर किसी को कुछ विशेषताओं की आवश्यकता नहीं होती है, इसलिए हम सबसे लोकप्रिय लोगों पर बस गए।

सामग्री

• जित संकलन
• सेक्शनिंग
• सूचकांक
• कवरिंग इंडिसेस
• एसपी जीएसटी
• उत्पादकता
• वाल
• बैकअप और प्रतिकृति
• Dba के लिए
• समानांतर निष्पादन
• optimizers
• विंडो फ़ंक्शन
• पूर्ण पाठ खोज परिवर्तन
• Json (b) और पूर्ण पाठ
• पीएल / * प्रक्रियाएं
• pgbench
• PSQL संवर्द्धन

जित संकलन

PostgreSQL ने आखिरकार JIT संकलन, यानी बाइनरी कोड में प्रश्नों का संकलन किया है। ऐसा करने के लिए, JIT संकलन (Compile time 1 (--with-llvm)) लिए समर्थन के साथ PostgreSQL (Compile time 1 (--with-llvm)) । इसी समय, मशीन में एलएलवीएम संस्करण होना चाहिए जो 3.9 से कम नहीं है।

क्या तेजी ला सकती है JIT?

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

Compile time 2 मतलब है कि जेआईटी का उपयोग नहीं किया गया है। PostgreSQL में क्वेरी प्लानिंग का एक पल होता है, जब सिस्टम निर्णय लेता है कि JIT के लायक क्या है और क्या नहीं है। इस बिंदु पर, यह JIT और उसके बाद निष्पादक निष्पादित करता है।

JIT को प्‍लगेबल बनाया जाता है। डिफ़ॉल्ट रूप से, यह एलएलवीएम के साथ काम करता है, लेकिन आप किसी भी अन्य जेआईटी को जोड़ सकते हैं।



यदि आपने JIT के समर्थन के बिना PostgreSQL संकलित किया है, तो बहुत पहले सेटअप काम नहीं करता है। डेवलपर्स के लिए कार्यान्वित विकल्प, व्यक्तिगत जेआईटी कार्यों के लिए सेटिंग्स हैं।

अगला सूक्ष्म बिंदु jit_above_cost से संबंधित है। JIT स्वयं मुक्त नहीं है। इसलिए, PostgreSQL JIT ऑप्टिमाइज़ेशन के लिए डिफॉल्ट करता है यदि क्वेरी की लागत 100 हजार सशर्त तोते से अधिक है, जिसमें व्याख्या, विश्लेषण और इसी तरह मापा जाता है। यह मान यादृच्छिक पर चुना जाता है, इसलिए इस पर ध्यान दें।

लेकिन हमेशा जेआईटी चालू करने के बाद सब कुछ तुरंत काम नहीं करता है। आमतौर पर, हर कोई JIT के साथ तालिका * id = 600 क्वेरी का चयन करके प्रयोग करना शुरू कर देता है और वे विफल हो जाते हैं। शायद, यह किसी भी तरह अनुरोध को जटिल करने के लिए आवश्यक है, और फिर हर कोई एक विशाल डेटाबेस बनाता है और अनुरोध की रचना करता है। नतीजतन, PostgreSQL डिस्क की क्षमताओं पर टिकी हुई है, इसमें साझा बफ़र्स और कैश की क्षमता का अभाव है।

यहाँ एक पूरी तरह से सार उदाहरण है। विभिन्न आवृत्तियों के साथ 9 अशक्त क्षेत्र हैं, ताकि आप टपल विकृत के प्रभाव को नोटिस कर सकें।

select i as x1,
case when i % 2 = 0 then i else null end as x2,
case when i % 3 = 0 then i else null end as x3,
case when i % 4 = 0 then i else null end as x4,
case when i % 5 = 0 then i else null end as x5,
case when i % 6 = 0 then i else null end as x6,
case when i % 7 = 0 then i else null end as x7,
case when i % 8 = 0 then i else null end as x8,
case when i % 9 = 0 then i else null end as x9
into t
from generate_series(0, 10000000) i;

vacuum t;
analyze t;

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

set max_parallel_workers=0;
set max_parallel_workers_per_gather=0;
set jit_above_cost=0;
set jit_inline_above_cost=0;
set jit_optimize_above_cost=0;

यहाँ स्वयं अनुरोध है:

set jit=off;
explain analyze
select count(*) from t where
sqrt(pow(x9, 2) + pow(x8,2)) < 10000;

set jit=on;
explain analyze
select count(*) from t where
sqrt(pow(x9, 2) + pow(x8,2)) < 10000;

और यहाँ परिणाम है:

Planning Time: 0.71 ms
Execution Time: 1986.323 ms

VS

Planning Time: 0.060 ms
JIT:
Functions: 4
Generation Time: 0.911 ms
Inlining: true
Inlining Time: 23.876 ms
Optimization: true
Optimization Time: 41.399 ms
Emission Time: 21.856 ms
Execution Time: 949.112 ms

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

अगर सारांश दिया जाए, तो JIT संकलन में लगभग 80 ms लगे। JIT मुक्त क्यों नहीं है? अनुरोध को निष्पादित करने से पहले, आपको इसे संकलित करने की आवश्यकता है, और इसमें समय भी लगता है। और योजना से अधिक परिमाण के तीन आदेश। एक महंगी खुशी नहीं है, लेकिन यह निष्पादन की लंबाई के कारण भुगतान करता है।

इस तरह से आप जेआईटी का उपयोग कर सकते हैं, हालांकि यह हमेशा फायदेमंद नहीं होता है।

सेक्शनिंग

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

संस्करण 11 में, विभाजन में बहुत सुधार हुआ है:

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

बड़ा सवाल यह है: मेरे पास कितने सेक्शन हो सकते हैं? ईमानदारी से, बड़ी संख्या में वर्गों (हजारों और दसियों हजारों) की सुविधा अच्छी तरह से काम नहीं करती है। Pg_pathman बेहतर करता है।

डिफ़ॉल्ट रूप से भी अनुभाग बनाए गए हैं। फिर से, pg_pathman में आप अनुभागों का स्वचालित निर्माण कर सकते हैं, जो अधिक सुविधाजनक है। यहाँ, जो कुछ भी नहीं दिखाया जा सकता था वह सब कुछ नीचे की ओर आता है। यदि डिफ़ॉल्ट रूप से ऐसा करने के लिए एक वास्तविक प्रणाली में, तो कुछ समय बाद आपको ऐसी गड़बड़ी मिलती है, जो तब आपको रेक करने के लिए पीड़ा देती है।

PostgreSQL 11 विभाजन को अनुकूलित करने में सक्षम है यदि दो तालिकाएँ एक विभाजन कुंजी और विभाजन योजनाओं से जुड़ती हैं। यह एक विशेष पैरामीटर द्वारा नियंत्रित किया जाता है, जिसे डिफ़ॉल्ट रूप से बंद कर दिया जाता है।

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

"नया क्या है" अनुभाग में, एक अद्भुत बात का उल्लेख किया गया है - किसी अनुरोध को निष्पादित करते समय वर्गों को बाहर निकालने की क्षमता। आइए देखें कि यह कैसे काम करता है। परिणाम एक ऐसी तालिका है:



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



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



अनुरोध पर ध्यान दें। हम एक गैर-विभाजित तालिका से सब कुछ का चयन करते हैं, एक विभाजन से कनेक्ट करते हैं। हम एक छोटा सा टुकड़ा लेते हैं और केवल एक प्रकार का चयन करते हैं, वे एक के माध्यम से जाते हैं। हम इंगित करते हैं कि ऑस कॉलम का एक मूल्य होना चाहिए। यह ठोस ड्राइवरों के चयन का पता लगाता है।

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

सूचकांक

• नीरस तरीके से बोली अनुकूलन, यानी बी-ट्री। हर कोई जानता है कि जब आप नीरस रूप से बढ़ते डेटा सम्मिलित करते हैं, तो यह बहुत तेजी से नहीं निकलता है। अब PostgreSQL अंतिम पृष्ठ को एक विशेष तरीके से कैश करने में सक्षम है और सम्मिलित करने के लिए रूट से सभी रास्ते पर नहीं जाता है। यह काम को काफी तेज करता है।
• PostgreSQL 10 ने हैश इंडेक्स का उपयोग करना संभव बना दिया क्योंकि उसने वाल (आगे लॉग लिखना) का उपयोग करना शुरू कर दिया। पहले, हमें मान मिला, पृष्ठ को अनलॉक किया, मान लौटाया। अगले मूल्य के लिए, आपको पृष्ठ को फिर से ब्लॉक करना होगा, वापस करना होगा, अनलॉक करना होगा, और इसी तरह। अब हैश बहुत तेज हो गया है। यह आपको हैश इंडेक्स से एक रिकॉर्ड प्राप्त करने के लिए एक समय में एक पृष्ठ को ब्लॉक करने की अनुमति देता है, वहां से सभी मान लौटाता है और इसे अनलॉक करता है। अब इसे एचएएसएच, जीएसटी और जीआईएन के लिए लागू किया गया है। भविष्य में, यह संभवतः SP-GiST के लिए लागू किया जाएगा। लेकिन अपने न्यूनतम / अधिकतम तर्क के साथ BRIN के लिए यह सिद्धांत रूप में नहीं किया जा सकता है।
• यदि आप कार्यात्मक सूचकांक का निर्माण करते थे, तो HOT अपडेट (हीप ओनली ट्यूपल) प्रभावी रूप से अक्षम हो गया था। जब PostgreSQL में एक रिकॉर्ड अपडेट किया जाता है, तो वास्तव में एक नई प्रतिलिपि बनाई जाती है, और इसके लिए सभी इंडेक्सों को चिपकाने की आवश्यकता होती है जो टेबल में होते हैं ताकि नया मूल्य नए टपल को इंगित करता है। इस तरह के अनुकूलन को लंबे समय तक लागू किया गया है: यदि अपडेट उन फ़ील्ड्स को नहीं बदलता है जो इंडेक्स में शामिल नहीं हैं और एक ही पृष्ठ पर मुफ्त स्थान है, तो इंडेक्स अपडेट नहीं किए जाते हैं, और ट्यूपल के पुराने संस्करण में, नए संस्करण के लिए एक पॉइंटर डाल दिया जाता है। यह आपको अपडेट के साथ समस्या की गंभीरता को कम करने की अनुमति देता है। हालाँकि, यदि आपके पास कार्यात्मक अनुक्रमणिकाएँ हैं, तो ऐसा अनुकूलन बिल्कुल काम नहीं करता है। PostgreSQL 11 में, इसने काम करना शुरू कर दिया। यदि आपने एक कार्यात्मक सूचकांक बनाया है और एक टपल को अपडेट किया है जो कि कार्यात्मक सूचकांक पर निर्भर करता है तो नहीं बदलता है, तो HOT अपडेट काम करेगा।

कवरिंग इंडिसेस

यह कार्यक्षमता तीन साल पहले PostgresPro द्वारा लागू की गई थी, और इस बार PostgreSQL ने इसे जोड़ने की कोशिश की। कवरिंग इंडेक्स का मतलब है कि आप अद्वितीय इंडेक्स में अतिरिक्त कॉलम जोड़ सकते हैं, सीधे इंडेक्स ट्यूपल में।

क्यों? हर कोई अपने त्वरित कार्य के लिए केवल इंडेक्स स्कैन करना पसंद करता है। इसके लिए, सशर्त रूप से "कवरिंग" सूचकांकों का निर्माण किया जाता है:



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

सच है, उसकी कुछ सीमाएँ हैं। अधिक सटीक रूप से, उन लाभों को जिन्हें तुरंत नहीं समझा जा सकता है। पहले क्रिएट इंडेक्स में c और d के कॉलम में स्केलर टाइप नहीं होते हैं जिसके लिए बी-ट्री इंडेक्स को परिभाषित किया जाता है। यही है, वे जरूरी नहीं कि एक कम-से-कम तुलना करें। यह अंक या बहुभुज हो सकते हैं। केवल एक चीज यह है कि ट्यूपल 2.7 Kb से कम होना चाहिए, क्योंकि सूचकांक में कोई टोशिंग नहीं है, लेकिन आप उस में फिट हो सकते हैं जिसकी तुलना नहीं की जा सकती।

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

ठीक है, इसके अलावा, आप इन कवर किए गए कॉलम को प्राथमिक कुंजी में जोड़ सकते हैं।

एसपी जीएसटी

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

इसके अलावा SP-GiST ने "प्रीफिक्स सर्च" ऑपरेशन शुरू किया। यह सच है अगर एक लाइन दूसरे का उपसर्ग है। उन्होंने इसे न केवल उस तरह पेश किया, बल्कि एसपी-जीएसटी के समर्थन के साथ इस तरह के अनुरोध के लिए।

SELECT * FROM table WHERE c ^@ „abc“

बी-ट्री में 2.7 Kb प्रति पंक्ति की सीमा है, लेकिन SP-GiST नहीं है। सच है, PostgreSQL की सीमा है: एक एकल मान 1 जीबी से अधिक नहीं हो सकता है।

उत्पादकता

• बिटमैप इंडेक्स केवल स्कैन दिखाई दिया है । यह क्लासिक इंडेक्स केवल स्कैन के रूप में काम करता है, सिवाय इसके कि यह किसी भी आदेश की गारंटी नहीं दे सकता है। इसलिए, यह केवल कुछ समुच्चय जैसे गणना (*) के लिए लागू होता है, क्योंकि बिटमैप सूचकांक से निष्पादनकर्ता तक फ़ील्ड को स्थानांतरित करने में सक्षम नहीं है। वह केवल एक रिकॉर्ड के तथ्य की रिपोर्ट कर सकता है जो शर्तों को पूरा करता है।
• अगला इनोवेशन वैक्यूम के एप्लिकेशन के दौरान फ्री स्पेस मैप का अपडेट है । दुर्भाग्य से, PostgreSQL के साथ काम करने वाले सिस्टम के डेवलपर्स में से कोई भी नहीं सोचता है कि टेबल के अंत में हटाना आवश्यक है, अन्यथा छेद, असंबद्ध स्थान दिखाई देते हैं। इसे ट्रैक करने के लिए, हमने एफएसएम को लागू किया, जो हमें तालिका को बड़ा करने की अनुमति नहीं देता है, लेकिन ट्यूल को voids में सम्मिलित करने की अनुमति देता है। पहले, यह वैक्यूम के साथ किया गया था, लेकिन अंत में। और अब वैक्यूम प्रक्रिया में ऐसा करने में सक्षम है, और भारी भारित प्रणालियों में यह टेबल के आकार को नियंत्रण में रखने में मदद करता है।
• वैक्यूम निष्पादन के दौरान इंडेक्स स्कैन को छोड़ने की संभावना । तथ्य यह है कि डेटाबेस सिद्धांत के अनुसार, सभी PostgreSQL अनुक्रमित को माध्यमिक कहा जाता है। इसका मतलब यह है कि अनुक्रमणिका को तालिका से दूर संग्रहीत किया जाता है; संकेत उनसे होते हैं। इंडेक्स केवल स्कैन आपको पॉइंटर्स पर इस जंप को नहीं करने की अनुमति देता है, लेकिन सीधे इंडेक्स से लेने के लिए। लेकिन वैक्यूम, जो रिकॉर्ड्स को हटा देता है, उन्हें इंडेक्स में नहीं देख सकता है और यह तय कर सकता है कि उन्हें डिलीट करना है या नहीं, क्योंकि इंडेक्स में ऐसा कोई डेटा नहीं है। इसलिए, वैक्यूम हमेशा दो पास में किया जाता है। सबसे पहले, वह तालिका के माध्यम से जाता है और पता करता है कि उसे क्या हटाने की आवश्यकता है। फिर यह इस तालिका से जुड़े अनुक्रमित पर जाता है, रिकॉर्ड को हटाता है जो पाया गया है, तालिका में लौटता है और जो इसे करने जा रहा था उसे हटा देता है। और सूचकांकों में जाने के चरण की हमेशा आवश्यकता नहीं होती है।
  
  यदि अंतिम वैक्यूम के बाद से कोई डिलीट या अपडेट नहीं था, तो आपके पास कोई मृत रिकॉर्ड नहीं है, आपको उन्हें हटाने की आवश्यकता नहीं है। इस मामले में, आप इंडेक्स में नहीं जा सकते। अतिरिक्त सूक्ष्मताएं हैं, बी-ट्री अपने पृष्ठों को तुरंत नहीं हटाता है, लेकिन दो पास में। इसलिए, यदि आपने तालिका में बहुत अधिक डेटा हटा दिया है, तो आपको वैक्यूम करने की आवश्यकता है। लेकिन अगर आप सूचकांकों में जगह खाली करना चाहते हैं, तो दो बार वैक्यूम करें।
  
  किसी को आश्चर्य होगा, यह कौन सी तालिका है जिसमें कोई डिलीट या अपडेट नहीं था? वास्तव में, कई लोग इससे निपटते हैं, बस सोचते नहीं हैं। ये केवल टेबल हैं, जहां, उदाहरण के लिए, लॉग जोड़े जाते हैं। उनमें, हटाने अत्यंत दुर्लभ है। और यह बहुत वैक्यूम / ऑटोवैक्यूम की अवधि को बचाता है, डिस्क पर लोड को कम करता है, कैश का उपयोग करता है और इसी तरह।
• एक साथ प्रतिस्पर्धी लेनदेन करें । यह एक नवाचार नहीं है, बल्कि एक सुधार है। अब PostgreSQL यह पता लगाता है कि यह अब प्रतिबद्ध होगा, और शेष लेन-देन की प्रतीक्षा करते हुए वर्तमान लेनदेन की प्रतिबद्धताओं को समाप्त कर देगा। कृपया ध्यान दें कि यदि आपके पास 2-4 कोर वाला एक छोटा सर्वर है तो इस सुविधा का बहुत कम प्रभाव पड़ता है।
• postgres_fdw (विदेशी डेटा आवरण) । एफडीडब्लू बाहरी डेटा स्रोत को जोड़ने का एक तरीका है ताकि यह एक वास्तविक पोस्ट-कांग्रेस जैसा दिखे। postgres_fdw आपको अपने उदाहरण से पड़ोसी तालिका से कनेक्ट करने की अनुमति देता है, और यह लगभग एक वास्तविक की तरह दिखाई देगा। अब अद्यतन और हटाने के लिए प्रतिबंधों में से एक को हटा दिया गया है। PostgreSQL अक्सर अनुमान लगा सकता है कि आपको कच्चा डेटा भेजने की आवश्यकता है। जुड़ने के अनुरोध को निष्पादित करने का तरीका काफी सरल है: हम इसे अपनी मशीन पर निष्पादित करते हैं, हम उदाहरण के लिए FDW का उपयोग करके तालिका को बाहर निकालते हैं, उस आईडी प्राथमिक कुंजी का पता लगाते हैं जिसे हमें हटाने की आवश्यकता है, और फिर अद्यतन और / या हटाने को लागू करें, अर्थात्, डेटा जो हम आगे और पीछे जाते हैं। । अब यह संभव है। बेशक, यदि टेबल अलग-अलग मशीनों पर हैं, तो यह इतना आसान नहीं है, लेकिन एफडीडब्ल्यू आपको दूरस्थ मशीन के संचालन करने की अनुमति देता है, और हम बस इंतजार कर रहे हैं।
• toast_tuple_target । ऐसी स्थितियां हैं जब डेटा थोड़ा सीमा से परे चला जाता है जिसके बाद टोस्ट करना आवश्यक है, लेकिन एक ही समय में ऐसे मूल्यों का टोस्ट हमेशा सुखद नहीं होता है। मान लें कि आपके पास 90 बाइट्स की सीमा है, और आपको 100 फिट की आवश्यकता है। आपको 10 बाइट्स के लिए टोस्ट शुरू करना होगा, उन्हें अलग से जोड़ना होगा, फिर जब आप इस फील्ड को चुनते हैं तो आपको टोस्ट इंडेक्स में जाने की जरूरत है, यह पता करें कि आवश्यक डेटा कहां है, टोस्ट टेबल पर जाएं। इकट्ठा करो और दे दो।

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

वाल

• वाल (लिखें आगे लॉग इन करें) एक राइट फॉरवर्ड लॉग है। वाल सेगमेंट का आकार अब initdb में सेट किया गया है। अच्छाई का शुक्रिया, संकलन करते समय नहीं।
• तर्क भी बदल गया है। इससे पहले, वाल सेगमेंट के सेट को तपस्या चौकी के क्षण से बचाया गया था, और अब आखिरी से। यह संग्रहीत डेटा की मात्रा को काफी कम कर सकता है। लेकिन अगर आपके पास 1 टीबी डेटाबेस है, और टीपीएस = 1, यानी प्रति सेकंड एक अनुरोध, तो आपको अंतर नहीं दिखेगा।

बैकअप और प्रतिकृति

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

Dba के लिए

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

समानांतर निष्पादन

• बी-ट्री इंडेक्स का समानांतर निर्माण । संस्करण 11 में, कई श्रमिकों में बी-ट्री इंडेक्स एम्बेड करना संभव हो गया। यदि आपके पास वास्तव में अच्छी मशीन है, कई डिस्क और कई कोर हैं, तो आप समानांतर में अनुक्रमित बना सकते हैं, यह प्रदर्शन में ध्यान देने योग्य वृद्धि का वादा करता है।
• जल्लाद के लिए एक साझा हैश तालिका का उपयोग करके समांतर कनेक्शन । , -. , . - , . .
• , union, create table as, select create materialized view!
• - (limit) . .

:

alter table usr reset (parallel_workers)
create index on usr(lower((so).occ)) — 2
alter table usr set (parallel_workers=2)
create index on usr(upper((so).occ)) — 1.8

parallel worker. . 16 4 ( ) 2 ., — 1,8 . , , . , .

:

explain analyze
select u1.* from usr u, usr1 u1 where
u.id=u1.id+0

, . , user — , . . , , .

, PostgreSQL 11 .



1425 , 1,5 . 1,4 . 2 . , 9.6 : 1 — 1 ., 2 1 . , 10 tuple. 11 . : user, batch, x-scan append .

:



. 211 , 702 . , 510 1473. , 2 .

parallel hash join. . — 4. , .

parallel index scan . batch . ? hash join, . user . , parallel hash, .

1 . , OLAP-, OLTP . OLTP , .

.

• . , . , «» «», index scan, . (highly skewed data), , . . , , .
• «», .

Window-

SQL:2011, .

, , . , , , , , .

websearch, . , . , .

# select websearch_to_tsquery('dog or cat');
----------------------
'dor' | 'cat'
# select websearch_to_tsquery('dog -cat');
----------------------
'dor' & !'cat'
# select websearch_to_tsquery('or cat');
----------------------
'cat'

— dog or cat — . Websearch . | , . “or cat”. , . websearch “or” . , -, .

Websearch — . : , . , .

Json(b)

10- , 11- . json json(b), tsvector. ( json(b)) - . , , , bull, numeric, string, . .

# select jsonb_to_tsvector
('{"a":"texts", "b":12}', '"string"');
-------------------
'text':1
# select jsonb_to_tsvector
('{"a":"texts", "b":12}', '["string", "numeric"]');
-------------------
'12':3 'text':1

json(b), . , , , .

PL/*

.

CREATE PROCEDURE transaction_test1()
LANGUAGE plpgsql
AS $$
BEGIN
FOR i IN 0..9 LOOP
INSERT INTO test1 (a) VALUES (i);
IF i % 2 = 0 THEN
COMMIT;
ELSE
ROLLBACK;
END IF;
END LOOP;
END
$$;
CALL transaction_test1();

call, , . . . select, insert .

, , PostgreSQL . Perl, Python, TL PL/pgSQL. Perl sp begin, .

PL/pgSQL : , .

pgbench

pgbench ICSB bench — , , . if, , . case, - . --init-steps , , .

random-seed. zipfian- . / — , . - , , - , .

, , - .

PSQL

, PSQL, . exit quit.

• — copy, 2 ³² . copy : 2 ³² - . , 2 ³¹ 2 ³² copy . 64- , 2 ⁶⁴ .
• POSIX : NaN ⁰ = 1 1 ^NaN = 1.