एक रिलीज़ के बाद कोई query धीमी हो गई। बताइए आप query plan कैसे पढ़ते हैं और क्या बदलना है यह कैसे तय करते हैं।

explain analyze चलाकर असली plan लें, जिसमें actual row counts और timings होती हैं, फिर सबसे ज़्यादा समय खाने वाला node देखें और estimated rows की actual rows से तुलना करें। बड़ा अंतर मतलब statistics खराब हैं, इसलिए planner ने गलत join या scan चुना। बड़ी टेबल्स पर sequential scans, किसी underestimate से चलने वाले nested loops, और disk पर spill होते sorts खोजें। हल index, अपडेटेड statistics, या ऐसा दोबारा लिखा हुआ predicate है जिसे index इस्तेमाल कर सके।

मैं explain analyze और buffers से शुरू करता हूं ताकि असली timings और row counts मिलें, और आदर्श रूप से production जितने डेटा पर, क्योंकि छोटे dataset का plan मुझे कुछ नहीं बताता। फिर मैं वह node ढूंढता हूं जिसके पास सबसे ज़्यादा समय है और उसका estimate actual से मिलाता हूं। अगर उसने एक row का अंदाज़ा लगाया और पचास हज़ार मिलीं, तो planner ने nested loop चुना है जो अब आफत है, और असली वजह आमतौर पर पुरानी statistics या कोई correlated predicate होती है जिसे planner model नहीं कर पाता। उसके बाद मैं आम मुजरिम देखता हूं: बड़ी टेबल पर sequential scan, ऐसा filter जो index condition हो सकता था, disk पर spill होता sort, या column के चारों ओर लिपटा कोई function जिससे index बेकार हो जाता है। पिछली बार मेरा मामला यही आखिरी वाला था, email column पर एक lower call जो index को नज़रअंदाज़ कर रहा था; lower of email पर एक functional index ने इसे लगभग 900 मिलीसेकंड से घटाकर दो पर ला दिया। फिर मैं plan दोबारा चलाकर पक्का करता हूं कि उसका आकार बदला है, क्योंकि गर्म cache पर तेज़ चलना कुछ साबित नहीं करता।