Aku bertanya-tanya hal yang sama. Saya menemukan dua cara alternatif untuk melakukan ini, tetapi yang Anda sarankan lebih cepat.
Saya secara informal membandingkan salah satu tabel kami yang lebih besar. Saya membatasi kueri ke 4 juta baris pertama. Saya berganti-ganti antara dua kueri untuk menghindari memberikan satu keuntungan yang tidak adil karena caching db.
Melalui epoch/waktu unix
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
(Perhatikan ini menghasilkan timestamptz bahkan jika Anda menggunakan tipe data yang tidak diketahui zona waktu)
Hasil
- Jalankan 1 :39,368 detik
- Jalankan 3 :39,526 detik
- Lari 5 :39,883 detik
Menggunakan date_trunc dan 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
Hasil
- Jalankan 2 :34.189 detik
- Jalankan 4 :37,028 detik
- Jalankan 6 :32,397 detik
Sistem
- Versi DB:PostgreSQL 9.6.2 pada x86_64-pc-linux-gnu, dikompilasi oleh gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bit
- Inti:Intel® Xeon®, E5-1650v2, Hexa-Core
- RAM:64 GB, RAM DDR3 ECC
Kesimpulan
Versi Anda tampaknya lebih cepat. Tetapi tidak cukup cepat untuk kasus penggunaan khusus saya. Keuntungan tidak harus menentukan jam membuat versi Epoch lebih fleksibel dan menghasilkan parameterisasi yang lebih sederhana dalam kode sisi klien. Ini menangani 2 hour interval serta 5 minute interval tanpa harus menabrak date_trunc argumen unit waktu ke atas. Sebagai catatan akhir, saya berharap argumen satuan waktu ini diubah menjadi argumen interval waktu.
