Postgres 16 query planner में क्या नया है

मूल लेख ↗ Hacker News चर्चा ↗

PostgreSQL 16 के query planner में सुधार इस बात पर नए सिरे से ध्यान खींच रहे हैं कि database query plans कैसे चुनता और execute करता है, खासकर nested loop joins जैसी जोखिमभरी choices और incomplete statistics के प्रभाव को लेकर। Contributors query hints या plan “freezing” जोड़ने पर लंबे समय से चल रही बहस पर विचार करते हैं, ताकि optimizer जब pathological plans चुने तो एक escape hatch मिल सके; साथ ही बेहतर statistics, execution से planner feedback, और EXPLAIN plans को visualize व tune करने वाले tools जैसे विकल्पों की भी पड़ताल करते हैं। वे व्यावहारिक समस्याएँ भी उजागर करते हैं—JIT compilation overhead, shared plan caching की कमी, और SQL Server जैसे systems से अंतर—और सामान्यतः मानते हैं कि PostgreSQL बड़े workloads संभाल सकता है, लेकिन उसे और अधिक predictable तथा self-correcting बनने की गुंजाइश अभी भी है.

Query Hints बनाम Planner Purism

  • एक बड़ा, बार-बार लौटने वाला विवाद: क्या Postgres को query hints का समर्थन करना चाहिए?
  • Hints के पक्ष में तर्क:
    • जब planner production में बहुत खराब plans चुनता है, तब एक “escape hatch” के रूप में यह महत्वपूर्ण है।
    • जल्दी mitigation, बेहतर plans की validation, और versions के बीच consistent performance के लिए उपयोगी।
    • Out-of-band hints (per queryid, stored outlines) और यहाँ तक कि “इस plan को freeze कर दो” जैसी क्षमताओं की इच्छा।
  • विरोध में तर्क / चिंताएँ:
    • Data और versions बदलने पर hints खराब हो सकते हैं, जिससे खराब plans भी lock हो जाते हैं।
    • ये खराब DBA habits को बढ़ावा देते हैं और maintainability को नुकसान पहुँचाते हैं।
    • Postgres culture hard hints के बजाय planner को ही सुधारने और richer statistics का उपयोग करने को प्राथमिकता देती है।
  • समझौते के विचार: ऐसे softer hints जो specific join types को force करने के बजाय selectivity estimates या risk tolerance को प्रभावित करें।

Statistics, Selectivity, और Plan Risk

  • कई धीमे plans खराब row-count/selectivity estimates से आते हैं (जैसे, 1 row मान लेना, nested loops चुनना, और फिर बहुत सारी rows मिलना)।
  • Extended statistics, column correlations, और मौजूदा heuristics (independent probabilities को multiply करना) पर चर्चा।
  • निम्नलिखित की इच्छा:
    • जब estimates अनिश्चित हों, तब अधिक “risk-averse” planning।
    • data-shape knowledge व्यक्त करने की क्षमता (monotonic time series, expected table size)।
    • execution से planner feedback और समय के साथ खराब plans से संभवतः “सीखने” की क्षमता।
    • भारी OLAP queries के लिए long-running / multi-pass planning।

JIT Compilation

  • कई users रिपोर्ट करते हैं कि JIT queries को बहुत धीमा कर देता है, खासकर many-join या partition-heavy queries में।
  • JIT को कब enable करना है, इसके heuristics को कमजोर माना जाता है; कुछ लोग इसे global रूप से disable कर देते हैं, खासकर OLTP के लिए।
  • मौजूदा JIT code cached नहीं है; caching enable करने और cost modeling सुधारने का काम उल्लेखित है।
  • सामान्य भावना: parallel query भरोसेमंद रूप से मददगार है; JIT शक्तिशाली है, लेकिन default के रूप में जोखिम भरा है।

Plan Inspection & Tooling

  • explain visualizers (pev2, pgMustard, आदि) जैसे visual tools की सराहना की जाती है।
  • हालांकि, यह समझना कि कोई plan “bad” है या नहीं और उसे कैसे fix करना है, अभी भी joins, indexes, और statistics के गहरे ज्ञान की मांग करता है।
  • EXPLAIN ANALYZE को आवश्यक माना गया है; estimate-vs-actual row mismatches बड़े red flags हैं।

Postgres बनाम अन्य Databases

  • कुछ लोगों का दावा है कि MSSQL/Oracle में अधिक mature optimizers, plan caching, hints, और आसपास का ecosystem (jobs, reporting, messaging) है।
  • दूसरे लोग नोट करते हैं कि Postgres व्यवहार में अच्छी तरह scale करता है; अंतर raw capability से अधिक features और tooling के बारे में हैं।