Postgres 16 query planner की नई सुविधाएँ

PostgreSQL 16 query planner की नई सुविधाएँ

• PostgreSQL 16 ने query planner में कई सुधार जोड़े हैं, जिनकी वजह से कई SQL queries पिछले versions की तुलना में अधिक तेज़ चलती हैं।
• PG16 release notes में इन planner improvements को देखा जा सकता है, लेकिन हर PostgreSQL release में इतने बदलाव होते हैं कि हर बदलाव का विस्तार से वर्णन देना कठिन होता है।
• यह blog post PostgreSQL 16 query planner में किए गए 10 सुधारों का गहन विश्लेषण देती है, और PG15 व PG16 planner output की तुलना के साथ बदले हुए हिस्सों के उदाहरण भी प्रदान करती है।

PostgreSQL 16 query planner के 10 सुधार

• Incremental sort: PostgreSQL 13 में पहली बार पेश किया गया incremental sort उन स्थितियों का लाभ उठाता है जहाँ result set का कुछ हिस्सा पहले से एक या अधिक leading columns पर sorted होता है, और फिर केवल बाकी columns के लिए sort करता है।
• Sorted data का उपयोग करने वाले aggregates: PostgreSQL 16 query planner अब ऐसे plans बनाने की कोशिश करता है जो aggregate node को sorted order में rows प्रदान करें।
• Memoization: PostgreSQL 14 में पहली बार जोड़ा गया memoization plan node duplicate value lookups से बचने के लिए cache layer की तरह काम करता है।
• Anti join: PostgreSQL 16 anti join करते समय छोटे table को hash करने की अनुमति देता है।
• Parallel hash join: PostgreSQL 16 अब FULL और RIGHT join types के लिए parallel hash join को support करता है।
• Window function optimization: PostgreSQL 16, ROWS mode का उपयोग करते समय, RANGE mode की तुलना में तेज़ window functions चलाने में सक्षम बनाता है।
• हमेशा बढ़ने वाले window functions का optimization: PostgreSQL 16 ntile(), cume_dist(), percent_rank() जैसे window functions के लिए optimization को और विस्तारित करता है।
• Partitioned tables में join removal: PostgreSQL 16 partitioned tables में LEFT JOIN removal optimization की अनुमति देता है।
• DISTINCT queries के लिए Limit का उपयोग: जब PostgreSQL 16 query planner यह पहचान लेता है कि सभी rows में एक ही value है, तो वह result से duplicates हटाने के लिए plan node शामिल नहीं करता।
• Merge Join के लिए नियमों में ढील: PostgreSQL 16 query planner अब Merge Join पर विचार करते समय यह नहीं देखता कि rows का क्रम पूरी तरह सटीक मेल खाता हो, बल्कि यह जाँचता है कि कम-से-कम एक leading column सही तरह से sorted है।

GN⁺ की राय

• PostgreSQL 16 के query planner सुधार database performance बढ़ाने में महत्वपूर्ण भूमिका निभाते हैं। खासकर incremental sort और memoization जैसी सुविधाएँ complex queries को अधिक कुशलता से चलाने में मदद करती हैं।
• ये सुधार PostgreSQL का उपयोग करने वाले developers और database administrators के लिए बहुत उपयोगी होंगे, और खासकर large-scale data संभालने वाले systems में performance improvements स्पष्ट रूप से महसूस किए जा सकेंगे।
• PostgreSQL community का लगातार innovation और improvement पर फोकस open source database technology की प्रगति को आगे बढ़ा रहा है, जिससे users और companies को बेहतर data management solutions मिलते हैं।

[GN⁺]

Hacker News राय

• एक राय है कि अच्छा होगा अगर Postgres query planner execution के बीच में query को फिर से plan कर सके। data distribution की जानकारी की कमी के कारण अक्षम query plans बन सकते हैं, और इससे execution time पर बड़ा असर पड़ सकता है। अगर query उम्मीद से धीमी चल रही हो, तो मौजूदा progress information के आधार पर query को फिर से plan करने की क्षमता चाहिए। हालांकि, Postgres streaming queries को support करता है, इसलिए execution के बीच plan बदलने के लिए काफ़ी बड़े infrastructure changes की ज़रूरत होगी।
• एक उपयोगकर्ता ने बताया कि वह query visualization tools के रूप में explain.dalibo.com और www.pgexplain.dev का उपयोग करता है। दोनों tools लगभग समान output देते हैं।
• एक राय है कि query planner improvements database का महत्वपूर्ण हिस्सा हैं, लेकिन वे ज़्यादातर तभी नज़र आते हैं जब चीज़ें मनचाहे तरीके से काम नहीं करतीं। हाल के Postgres versions में JIT(Just-In-Time) compiler के उपयोग-समय heuristics काफ़ी robust नहीं लगते, और छोटे data पर यह performance धीमी कर सकता है, इसलिए अनुभव के आधार पर JIT को disable करना बेहतर हो सकता है।
• एक राय है कि यह जानना दिलचस्प होगा कि वास्तविक queries में ये बदलाव कितनी बार असरदार साबित होते हैं, खासकर "जहाँ संभव हो DISTINCT की जगह Limit का उपयोग" जैसे बदलाव वास्तव में कितनी बार लागू होते हैं। यह भी सवाल है कि क्या Postgres developers के पास इस बारे में कोई जानकारी है।
• एक राय है कि application testing के लिए एक "strict mode" होना चाहिए। इस mode में अगर query को बेहतर बनाने वाला कोई index मौजूद न हो, तो error लौटे, और CREATE INDICES FOR <sql> command के ज़रिए ज़रूरी indexes बनाए जा सकें। development और interactive use के लिए automatic index creation mode का सुझाव भी दिया गया।
• एक उपयोगकर्ता ने कहा कि उसका एक दोस्त छोटे और मध्यम व्यवसायों के लिए Microsoft DBA के रूप में काम करता है, और उसका दावा है कि Postgres में गंभीर काम नहीं किया जा सकता। उसने यह कहकर हैरानी जताई कि Postgres में query planner नहीं है, लेकिन यह ग़लत जानकारी है। साथ ही यह सवाल उठाया गया कि MSSQL के Postgres की तुलना में बड़े scale के workloads संभालने के दावे में कितनी विश्वसनीयता है।
• यह सवाल उठाया गया कि Postgres hints को implement क्यों नहीं करता।
• यह प्रश्न पूछा गया कि Citus Data द्वारा घोषित feature postgresql.org की बजाय किसी और जगह से क्यों आया, और क्या वह paid feature है या open source extension।
• यह सवाल पूछा गया कि Postgres IS NOT DISTINCT FROM query को तेज़ करने के लिए index का उपयोग किस समय कर सकता है।
• एक comment को report किए जाने के बाद flagged कर दिया गया।