इंडेक्स जोड़ने से पहले PostgreSQL का EXPLAIN प्लान पढ़ें

अनुमान से शुरू करें

क्वेरी चलाना भारी पड़ सकता हो तो पहले साधारण EXPLAIN इस्तेमाल करें। Cost प्लानर की इकाइयों में होती है, बीते हुए मिलीसेकंड में नहीं। Sequential scan अपने-आप गलत नहीं होता; छोटी तालिका का बड़ा हिस्सा पढ़ना हो तो वह उचित हो सकता है।

EXPLAIN SELECT * FROM orders WHERE customer_id = 42;

उपयुक्त एनवायरनमेंट में मापें

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

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders WHERE customer_id = 42;

पूरे tree से पहले एक line समझें

नीचे केवल illustrative plan है, वास्तविक database का माप नहीं। cost=0.43..8.61 अनुमानित startup और total cost है, planner units में। rows=10 अपेक्षित output count और width=16 एक output row का औसत अनुमानित byte आकार है।

मापा भाग एक execution में अपेक्षित 10 की जगह 10,000 rows दिखाता। actual time=0.05..12.00 पहली row और completion तक milliseconds बताता है। Rows में बड़ा अंतर पहले estimation देखने का कारण है, तुरंत एक और index बनाने का नहीं।

Index Scan using orders_customer_idx on orders
  (cost=0.43..8.61 rows=10 width=16)
  (actual time=0.05..12.00 rows=10000 loops=1)

नीचे से पढ़ें और दोहराया काम देखें

Indentation दिखाती है कौन-से nodes अपने parent को डेटा देते हैं। Scan, join, sort या aggregate को rows देता है। देखें काम कहाँ बढ़ता है: बहुत rows हटाने वाला filter, बड़ा sort या बार-बार चलता inner node।

साधारण node में actual rows और time प्रति execution का औसत हैं। actual rows=5 और loops=1000 का कुल लगभग 5,000 rows है। Node time में children शामिल हो सकते हैं; सब जोड़ने से काम दो बार गिना जाता है। Parallel plans में अतिरिक्त समझ चाहिए; पूरी अवधि के लिए Execution Time देखें।

Buffers और statistics से कारण स्पष्ट करें

BUFFERS डेटा access बताता है। shared hit का अर्थ PostgreSQL shared buffer cache में block मिला। shared read का अर्थ block buffers में पढ़ा गया, शायद OS cache से। ये accesses की गिनती हैं, जरूरी नहीं अलग blocks या physical disk reads हों।

पुरानी statistics या असमान distribution बड़ी estimate गलती दे सकती है। ANALYZE orders table statistics जुटाता है; EXPLAIN ANALYZE query चलाता है। Bulk बदलाव के बाद पहले statistics देखें। Disk पर spill हुआ sort और गलत estimated join की जाँच अलग होगी।

ANALYZE orders;

एक बदलाव करें और समान परिस्थिति में तुलना करें

Hypothesis लिखें: बहुत असंबंधित rows पढ़ना, lookup अधिक दोहराना या बड़ा intermediate result sort करना। Selective filter उचित index से लाभ पा सकता है। छोटी table या अधिकतर rows लौटाने में sequential scan सही रह सकता है।

Parameters और dataset तुलनीय रखें। माप दोहराएँ: cache और concurrent load समय बदलते हैं। एक तेज warm run सार्वभौमिक सुधार नहीं है। Index का storage और write overhead भी देखें। उचित environment में सुरक्षित SELECT से शुरू करें; EXPLAIN ANALYZE modifying statements भी चलाता है और side effects हो सकते हैं।