केवल कुछ चीजें हैं जो इस प्रश्न में मदद करेंगी:
-
वास्तविक स्कैनिंग समस्या नहीं लगती (इसमें 42 सेकंड का समय लगा), लेकिन यदि तालिका को RAM में रखा जा सकता है, तो यह तेज़ हो सकता है।
-
आपकी मुख्य समस्या प्रकार है, जो PostgreSQL पहले से ही समानांतर है।
कुछ चीज़ें हैं जिन्हें आप ट्यून कर सकते हैं:
-
बढ़ाएँ
work_memजितना संभव हो सके, जो क्रम को तेज कर देगा। -
बढ़ाएँ
max_worker_processes(इसे पुनः आरंभ करने की आवश्यकता होगी),max_parallel_workersऔरmax_parallel_workers_per_gatherताकि क्वेरी के लिए अधिक कोर का उपयोग किया जा सके।PostgreSQL में एक तालिका के लिए उपयोग करने के लिए तैयार समानांतर श्रमिकों की अधिकतम संख्या की गणना करने के लिए एक आंतरिक तर्क है:यह जितने समानांतर श्रमिकों पर विचार करेगा
लॉग<उप>3 (तालिका आकार /
min_parallel_table_scan_size)आप इसे इससे अधिक प्रक्रियाओं का उपयोग करने के लिए बाध्य कर सकते हैं:
ALTER TABLE ohlcv SET (parallel_workers = 20);लेकिन
max_parallel_workersअभी भी ऊपरी सीमा है।
-
यदि टेबल पर कोई डिलीट और अपडेट नहीं है, और डेटा को क्रमबद्ध क्रम में डाला गया है, तो आप ORDER BY को छोड़ कर दूर हो सकते हैं खंड, बशर्ते आपने synchronize_seqscans = off . सेट किया हो ।
