व्याख्या विश्लेषण को कैसे समझें

जबकि इस तरह की एक साधारण योजना के लिए उपयोगी नहीं है, https://explain.depesz.com वास्तव में उपयोगी है। https://explain.depesz.com/s/t4fi देखें। "आंकड़े" टैब और "विकल्प" पुलडाउन पर ध्यान दें।

इस योजना के बारे में ध्यान देने योग्य बातें:

• अनुमानित पंक्ति गणना (183) वास्तविक पंक्ति गणना (25) के लिए उचित रूप से तुलनीय है। यह सैकड़ों गुना अधिक नहीं है, न ही यह 1 है। जब पंक्ति गणना अनुमानों की बात आती है, या "1 बनाम 1 नहीं" मुद्दों की बात आती है तो आप परिमाण के क्रम में अधिक रुचि रखते हैं। (आपको "सरकारी काम के लिए पर्याप्त करीब" सटीकता की भी आवश्यकता नहीं है - "सैन्य अनुबंध लेखांकन के लिए पर्याप्त करीब" करेगा)। चयनात्मकता अनुमान और आँकड़े उचित लगते हैं।

• यह प्रदान किए गए दो-स्तंभ आंशिक अनुक्रमणिका का उपयोग कर रहा है (index scan using index_cars_onsale_on_brand_and_model_name का उपयोग करके अनुक्रमणिका स्कैन करें) ), इसलिए यह आंशिक अनुक्रमणिका स्थिति से मेल खाता है। आप इसे Filter: has_auto_gear . में देख सकते हैं . अनुक्रमणिका खोज स्थिति भी दिखाई जाती है।

• क्वेरी प्रदर्शन उचित लगता है क्योंकि तालिका की पंक्ति गणना का अर्थ यह होगा कि सूचकांक काफी बड़ा है, खासकर जब यह दो कॉलम से अधिक हो। मिलती-जुलती पंक्तियाँ बिखरी होंगी, इसलिए संभव है कि प्रत्येक पंक्ति के लिए एक अलग पृष्ठ को भी पढ़ने की आवश्यकता होगी।

मुझे यहां कुछ भी गलत नहीं दिख रहा है। हालांकि, इस क्वेरी से PostgreSQL 9.2 के केवल-इंडेक्स स्कैन से बहुत लाभ होने की संभावना है।

यह संभव है कि यहां कुछ टेबल ब्लोट हो, लेकिन 2-कॉलम इंडेक्स और पंक्तियों की विशाल संख्या को देखते हुए प्रतिक्रिया समय पूरी तरह से अनुचित नहीं है, खासकर 170 (!!) कॉलम वाली तालिका के लिए जो प्रत्येक में अपेक्षाकृत कुछ टुपल्स फिट होने की संभावना है पृष्ठ। यदि आप कुछ डाउनटाइम वहन कर सकते हैं तो VACUUM FULL try आज़माएं तालिका को पुनर्गठित करने और सूचकांक के पुनर्निर्माण के लिए। यह विशेष रूप से टेबल को कुछ समय के लिए लॉक कर देगा जबकि यह इसे फिर से बनाता है। यदि आप डाउनटाइम बर्दाश्त नहीं कर सकते, तो देखें pg_reorg और/या CREATE INDEX CONCURRENTLY और ALTER INDEX ... RENAME TO ।

आपको EXPLAIN (ANALYZE, BUFFERS, VERBOSE) मिल सकता है कभी-कभी अधिक जानकारीपूर्ण, क्योंकि यह बफर एक्सेस आदि दिखा सकता है।

एक विकल्प जो इस क्वेरी को तेज़ बना सकता है (हालाँकि यह अन्य प्रश्नों को कुछ हद तक धीमा करने का जोखिम उठाता है) तालिका को brand पर विभाजित करना है और constraint_exclusion को सक्षम करें . विभाजन देखें।