योजनाकार लागत पैरामीटर
यह मुझे बताता है कि आपकी random_page_cost और seq_page_cost शायद गलत हैं। आप तेजी से यादृच्छिक I/O के साथ भंडारण पर हैं - या तो क्योंकि अधिकांश डेटाबेस RAM में कैश किया गया है या क्योंकि आप SSD का उपयोग कर रहे हैं, कैश के साथ SAN, या अन्य संग्रहण जहां यादृच्छिक I/O स्वाभाविक रूप से तेज़ है।
कोशिश करें:
SET random_page_cost = 1;
SET seq_page_cost = 1.1;
लागत परम अंतर को बहुत कम करने और फिर से चलाने के लिए। यदि वह काम करता है तो उन पैरा को postgresql.conf. . में बदलने पर विचार करें ।
आपके पंक्ति-गणना अनुमान उचित हैं, इसलिए यह किसी योजनाकार के गलत आकलन की समस्या या खराब तालिका आंकड़ों की समस्या नहीं लगती।
गलत क्वेरी
आपकी क्वेरी भी गलत है। OFFSET 0 LIMIT 1 बिना ORDER BY . के अप्रत्याशित परिणाम देगा जब तक कि आपके पास ठीक एक मैच होने की गारंटी न हो, उस स्थिति में OFFSET ... LIMIT ... खंड अनावश्यक हैं और इन्हें पूरी तरह से हटाया जा सकता है।
आप आमतौर पर SELECT max(...) . जैसी क्वेरीज़ को phrasing करने से बहुत बेहतर होते हैं या SELECT min(...) जहां संभव; PostgreSQL महंगे टेबल स्कैन या इंडेक्स स्कैन और सॉर्ट किए बिना वांछित मूल्य को निकालने के लिए एक इंडेक्स का उपयोग करने में सक्षम होगा।
टिप्स
BTW, भविष्य के प्रश्नों के लिए PostgreSQL विकी के पास प्रदर्शन श्रेणी में कुछ अच्छी जानकारी है। और धीमी क्वेरी वाले सवाल पूछने के लिए गाइड ।
