私は同じことを考えていました。これを行う別の方法を2つ見つけましたが、あなたが提案した方法の方が高速でした。
私は、より大きなテーブルの1つに対して非公式にベンチマークを行いました。クエリを最初の400万行に制限しました。データベースキャッシングによる不当な利点を1つに与えないようにするために、2つのクエリを交互に使用しました。
エポック/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
(これにより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(Ubuntu 4.8.2-19ubuntu1)4.8.2、64ビットでコンパイル
- コア:Intel®Xeon®、E5-1650v2、Hexa-Core
- RAM:64 GB、DDR3 ECC RAM
結論
お使いのバージョンの方が速いようです。しかし、私の特定のユースケースには十分な速さではありません。時間を指定する必要がないという利点により、エポックバージョンの用途が広がり、クライアント側のコードでのパラメーター化が簡単になります。 2 hour
を処理します 5 minute
と同様の間隔 date_trunc
をバンプする必要のない間隔 時間単位の引数を上げます。最後に、この時間単位の引数が代わりに時間間隔の引数に変更されていることを望みます。