मैं उसी चीज़ पर हैरान हो रहा था। मुझे ऐसा करने के दो वैकल्पिक तरीके मिले, लेकिन आपने जो सुझाव दिया वह तेज़ था।
मैंने अनौपचारिक रूप से हमारी एक बड़ी टेबल के खिलाफ बेंचमार्क किया। मैंने क्वेरी को पहली 4 मिलियन पंक्तियों तक सीमित कर दिया। डीबी कैशिंग के कारण किसी को अनुचित लाभ देने से बचने के लिए मैंने दो प्रश्नों के बीच बारी-बारी से किया।
युग/यूनिक्स समय से गुजर रहा है
SELECT to_timestamp(
floor(EXTRACT(epoch FROM ht.time) / EXTRACT(epoch FROM interval '5 min'))
* EXTRACT(epoch FROM interval '5 min')
) FROM huge_table AS ht LIMIT 4000000
(ध्यान दें कि यह timestamptz उत्पन्न करता है भले ही आपने समय क्षेत्र अनजान डेटाटाइप का इस्तेमाल किया हो)
परिणाम
- 1 भागो :39.368 सेकंड
- 3 रन करें :39.526 सेकंड
- 5 भागो :39.883 सेकंड
date_trunc और date_part का उपयोग करना
SELECT
date_trunc('hour', ht.time)
+ date_part('minute', ht.time)::int / 5 * interval '5 min'
FROM huge_table AS ht LIMIT 4000000
परिणाम
- 2 भागो :34.189 सेकंड
- 4 रन करें :37.028 सेकंड
- 6 रन करें :32.397 सेकंड
सिस्टम
- DB संस्करण:x86_64-pc-linux-gnu पर PostgreSQL 9.6.2, gcc द्वारा संकलित (उबंटू 4.8.2-19ubuntu1) 4.8.2, 64-बिट
- कोर:Intel® Xeon®, E5-1650v2, Hexa-Core
- रैम:64 जीबी, डीडीआर3 ईसीसी रैम
निष्कर्ष
आपका संस्करण तेज़ प्रतीत होता है। लेकिन मेरे विशिष्ट उपयोग के मामले में पर्याप्त तेज़ नहीं है। समय निर्दिष्ट न करने का लाभ युग संस्करण को अधिक बहुमुखी बनाता है और क्लाइंट साइड कोड में सरल पैरामीटरकरण उत्पन्न करता है। यह 2 hour . को संभालता है अंतराल और साथ ही 5 minute date_trunc . से टकराए बिना अंतराल समय इकाई तर्क। अंत में, मेरी इच्छा है कि इस बार इकाई तर्क को समय अंतराल तर्क में बदल दिया गया था।
