वर्क_मेम को बढ़ाने से ऐसा लगता है कि सॉर्ट लगभग 8 गुना तेज हो गया है:(172639.670 - 169311.063) / (167975.549 - 167570.669) . लेकिन चूंकि सॉर्ट ने समग्र निष्पादन समय का केवल एक छोटा सा अंश लिया, इसलिए इसे 1000 गुना तेज बनाने से चीजें समग्र रूप से बेहतर नहीं हो सकती हैं। यह seq स्कैन है जो समय ले रहा है।
seq स्कैन में अधिकांश समय शायद IO पर व्यतीत होता है। आप EXPLAIN (ANALYZE, BUFFERS) . चलाकर देख सकते हैं Track_io_timeing को चालू करने के बाद।
इसके अलावा, एक seq स्कैन को समानांतर करना अक्सर बहुत मददगार नहीं होता है, क्योंकि रीडहेड के जादू के कारण IO सिस्टम आमतौर पर एक पाठक को अपनी पूरी क्षमता देने में सक्षम होता है। और कभी-कभी समानांतर पाठक एक-दूसरे के पैर की उंगलियों पर भी कदम रख सकते हैं, जिससे पूरा प्रदर्शन खराब हो जाता है। आप समानांतरकरण को set max_parallel_workers_per_gather TO 0; के साथ अक्षम कर सकते हैं यह चीजों को तेज कर सकता है, और यदि ऐसा नहीं होता है तो यह कम से कम EXPLAIN योजना को समझने में आसान बना देगा।
आप तालिका का 3% से अधिक प्राप्त कर रहे हैं:193963 / (193963 + 6041677) . जब आप इसे बहुत अधिक ला रहे हों तो अनुक्रमणिका बहुत उपयोगी नहीं हो सकती है। यदि वे होने हैं, तो आप एक संयुक्त सूचकांक चाहते हैं, व्यक्तिगत नहीं। तो आप (client, event_name, date(datetime)) . पर एक इंडेक्स चाहते हैं . फिर आपको date(datetime) . का उपयोग करने के लिए क्वेरी को बदलने की भी आवश्यकता होगी के बजाय to_char(datetime, 'YYYY-MM-DD') . आपको यह परिवर्तन करने की आवश्यकता है क्योंकि to_char अपरिवर्तनीय नहीं है, और इसलिए इसे अनुक्रमित नहीं किया जा सकता है।
