Pg_hint_plan: PostgreSQL को अपनी इच्छित तरीके से query plans execute करने के लिए मजबूर करें

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

pg_hint_plan क्या प्रदान करता है

  • यह extension उपयोगकर्ताओं को core PostgreSQL बदले बिना, PostgreSQL के planner को विशिष्ट plans (joins, indexes, आदि) की ओर झुकाने देता है।
  • इसे विशेष रूप से इन मामलों में मूल्यवान माना जाता है:
    • Production में emergency incidents, जब planner एक बेहद खराब plan चुन लेता है।
    • Research/experimentation, जहाँ आप कुछ plan choices को fix करना चाहते हैं और बाकी काम planner पर छोड़ना चाहते हैं।
    • अन्य databases से migration (जैसे Babelfish के माध्यम से), जहाँ मौजूदा workloads hints पर निर्भर करते हैं।

इसे इस्तेमाल करने में व्यावहारिक समस्याएँ

  • Hint table interface को fragile बताया गया है:
    • Matching whitespace-sensitive होती है और बिना किसी चेतावनी के fail हो सकती है।
    • Parameter handling awkward है; पहले के tooling ने parameterized queries पर iterate करना कठिन बना दिया था, हालांकि नए psql versions इसमें मदद करते हैं।
  • Extension plan costs को बदलकर किसी plan को “strongly suggest” करती है; यदि hinted plan असंभव है, तो PostgreSQL फिर भी कुछ और चुन लेता है।

बहस: Hints अच्छे हैं या बुरे?

  • चिंताएँ:
    • Data और PostgreSQL versions के बदलने के साथ hints suboptimal plans को स्थिर कर सकते हैं।
    • Developers hinted queries पर शायद ही वापस आते हैं; cruft जमा हो जाती है।
    • Core dev stance (जैसा वर्णित है): SQL में hints जोड़ने के बजाय statistics और optimizer को बेहतर बनाना चाहिए।
  • प्रतिवाद:
    • Production में predictability अक्सर theoretical optimality से अधिक महत्वपूर्ण होती है; अचानक plan regressions से बचना critical है।
    • Statistics और planner configuration जटिल, global, और जोखिमपूर्ण हैं; hints localized होते हैं और एक single query के लिए समझना आसान होता है।
    • PostgreSQL की statistics और optimizer में बड़े scale पर और correlated या skewed data के साथ ज्ञात कमजोरियाँ हैं; कुछ समस्याएँ वर्षों से unresolved हैं।
    • Hints को “inline assembly” की तरह देखा जाता है: default के रूप में खराब, लेकिन rare edge cases में अमूल्य।

वैकल्पिक और tuning approaches

  • Suggested non-hint remedies:
    • VACUUM ANALYZE, tuned autovacuum.
    • प्रति-column statistics targets बढ़ाना या extended/custom statistics का उपयोग करना।
    • Planner config tweaks (join_collapse_limit, cost parameters) को SET LOCAL के साथ scoped करना।
    • Schema/index changes (composite या partial indexes) ताकि frequent queries को बेहतर support मिले।

Planner से जुड़े दर्द बिंदु और उदाहरण

  • LIMIT + ORDER BY + WHERE queries के कई reports में बहुत खराब plans चुने जाने की बात कही गई है, खासकर correlated या skewed columns के साथ।
  • इस पर असहमति है कि catastrophic plan flips कितनी बार होते हैं, लेकिन इस बात पर सहमति है कि वे होते हैं, विशेषकर बहुत बड़ी tables पर।
  • कुछ लोगों का कहना है कि इससे PostgreSQL production में “dangerous” हो जाता है, बिना plans को pin या override करने के reliable तरीके के।