पहले शुद्धता :मुझे आपकी क्वेरी में एक बग का संदेह है:
LEFT JOIN historical_ohlcv ohlcv ON ohlcv.time_open >= g.start_time
AND ohlcv.time_close < g.end_time
मेरे संदर्भित उत्तर के विपरीत, आप एक समय पर शामिल होते हैं अंतराल :(time_open, time_close] . जिस तरह से आप इसे करते हैं उस तालिका में पंक्तियों को शामिल नहीं करता है जहां अंतराल बाल्टी सीमाओं को पार करता है। सिंगल बकेट काउंट में केवल अंतराल पूरी तरह से समाहित हैं। मुझे नहीं लगता कि यह इरादा है?
एक आसान समाधान यह होगा कि time_open . के आधार पर बकेट सदस्यता का निर्णय लिया जाए (या time_close ) अकेला। अगर आप दोनों के साथ काम करते रहना चाहते हैं, तो आपको बिल्कुल . को परिभाषित करना होगा एकाधिक बाल्टी के साथ ओवरलैपिंग अंतराल से कैसे निपटें।
साथ ही, आप max(high) . की तलाश में हैं प्रति बकेट, जो प्रकृति में count(*) . से भिन्न है मेरे संदर्भित उत्तर में।
और आपकी बाल्टी प्रति घंटे साधारण अंतराल हैं?
तब हम मौलिक रूप से सरल कर सकते हैं। केवल time_open के साथ कार्य करना :
SELECT date_trunc('hour', time_open) AS hour, max(high) AS max_high
FROM historical_ohlcv
WHERE exchange_symbol = 'BINANCE'
AND symbol_id = 'ETHBTC'
AND time_open >= now() - interval '5 months' -- frame_start
AND time_open < now() -- frame_end
GROUP BY 1
ORDER BY 1;
संबंधित:
- समय श्रृंखला डेटा पर पुन:नमूना
आगे के प्रदर्शन अनुकूलन के बारे में बात करना कठिन है जबकि मूल बातें स्पष्ट नहीं हैं। और हमें और जानकारी की आवश्यकता होगी।
WHERE हैं शर्तें चर?exchange_symbol . में कितने अलग-अलग मान हैं और symbol_id ?
औसत। पंक्ति का आकार? आपको इसके लिए क्या मिलता है:
SELECT avg(pg_column_size(t)) FROM historical_ohlcv t TABLESAMPLE SYSTEM (0.1);
क्या टेबल केवल पढ़ने के लिए है?
मान लें कि आप हमेशा exchange_symbol पर फ़िल्टर करते हैं और symbol_id और मान परिवर्तनशील हैं, आपकी तालिका केवल-पढ़ने के लिए है या ऑटोवैक्यूम लेखन भार के साथ बना रह सकता है ताकि हम केवल-अनुक्रमणीय स्कैन की आशा कर सकें, आपके पास एक बहु-स्तंभ अनुक्रमणिका सबसे अच्छा होगा पर (exchange_symbol, symbol_id, time_open, high DESC) इस क्वेरी का समर्थन करने के लिए। इस क्रम में इंडेक्स कॉलम। संबंधित:
- बहु-स्तंभ अनुक्रमणिका और प्रदर्शन
डेटा वितरण और अन्य विवरणों के आधार पर एक LEFT JOIN LATERAL समाधान एक और विकल्प हो सकता है। संबंधित:
- पोस्टग्रेज में समय अंतराल के लिए औसत मान कैसे खोजें
- प्रति उपयोगकर्ता नवीनतम रिकॉर्ड पुनर्प्राप्त करने के लिए क्वेरी द्वारा GROUP ऑप्टिमाइज़ करें
इन सबके अलावा, आप EXPLAIN योजना कुछ बहुत प्रदर्शित करती है खराब अनुमान :
- https://explain.depesz.com/s/E5yI
क्या आप वर्तमान . का उपयोग कर रहे हैं पोस्टग्रेज का संस्करण? आपको अपने सर्वर कॉन्फ़िगरेशन पर काम करना पड़ सकता है - या कम से कम प्रासंगिक कॉलम पर उच्च आंकड़े लक्ष्य और बड़ी तालिका के लिए अधिक आक्रामक ऑटोवैक्यूम सेटिंग्स सेट करना पड़ सकता है। संबंधित:
- पोस्टग्रेएसक्यूएल को कभी-कभी खराब क्वेरी प्लान चुनने से रोकें
- पोस्टग्रेएसक्यूएल पर आक्रामक ऑटोवैक्यूम
