PostgreSQL 12 में CTE में महत्वपूर्ण बदलाव

WITH w AS NOT MATERIALIZED ( SELECT * FROM very_very_big_table ) SELECT * FROM w AS w1 JOIN w AS w2 ON w1.key = w2.ref WHERE w2.key = 123; 

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

यह PostgreSQL 12 में जाएगा और यह एक बड़ी बात है। आइए नजर डालते हैं क्यों

प्रोग्रामर CTE से प्यार करते हैं क्योंकि यह कोड की पठनीयता में काफी सुधार कर सकता है। खैर, वास्तव में, कुछ विश्लेषणात्मक प्रश्न दर्जनों तालिकाओं और विभिन्न समूहों और फिल्टर के साथ काम कर सकते हैं। यह सब एक बड़ी क्वेरी में लिखने के लिए - बिना पढ़े कुछ पाने की गारंटी। इसलिए, ऑपरेटर के WITH का उपयोग करते हुए, हम क्रमिक रूप से, छोटी उपश्रेणियों में (जिन्हें मानव-पठनीय नाम दिया गया है) काम के तर्क का वर्णन करते हैं, और फिर परिणाम का उत्पादन करते हैं। बहुत सहज है।

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

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

सामान्य तौर पर, परिस्थितियां भिन्न होती हैं, यही वजह है कि Postgres 12 ने एक कीवर्ड बनाकर MATERIALIZED और NOT MATERIALIZED जोड़ा, जो यह बताता है कि क्रमशः क्वेरी या इनलाइन को भौतिक बनाना है या नहीं।

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