Ich habe mich das gleiche gefragt. Ich habe zwei alternative Möglichkeiten gefunden, dies zu tun, aber die von Ihnen vorgeschlagene war schneller.
Ich habe informell mit einem unserer größeren Tische verglichen. Ich habe die Abfrage auf die ersten 4 Millionen Zeilen beschränkt. Ich habe zwischen den beiden Abfragen gewechselt, um einen unfairen Vorteil durch db-Caching zu vermeiden.
Epoche/Unix-Zeit durchlaufen
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
(Beachten Sie, dass dies timestamptz erzeugt auch wenn Sie einen Datentyp verwendet haben, der die Zeitzone nicht kennt)
Ergebnisse
- Lauf 1 :39,368 Sekunden
- Lauf 3 :39,526 Sekunden
- Lauf 5 :39,883 Sekunden
Mit date_trunc und 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
Ergebnisse
- Lauf 2 :34,189 Sekunden
- Lauf 4 :37,028 Sekunden
- Run 6 :32,397 Sekunden
System
- DB-Version:PostgreSQL 9.6.2 auf x86_64-pc-linux-gnu, kompiliert von gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-Bit
- Kerne:Intel® Xeon®, E5-1650v2, Hexa-Core
- RAM:64 GB, DDR3-ECC-RAM
Schlussfolgerung
Deine Version scheint schneller zu sein. Aber nicht schnell genug für meinen speziellen Anwendungsfall. Der Vorteil, dass die Stunde nicht angegeben werden muss, macht die Epochenversion vielseitiger und erzeugt eine einfachere Parametrisierung im clientseitigen Code. Es verarbeitet 2 hour Intervalle genauso gut wie 5 minute Intervalle, ohne dass date_trunc erhöht werden muss Zeiteinheit Argument auf. Als Endbemerkung wünschte ich mir, dass dieses Zeiteinheitsargument stattdessen in ein Zeitintervallargument geändert würde.
