Ik vroeg me hetzelfde af. Ik heb twee alternatieve manieren gevonden om dit te doen, maar degene die je voorstelde was sneller.
Ik heb informeel vergeleken met een van onze grotere tabellen. Ik heb de query beperkt tot de eerste 4 miljoen rijen. Ik wisselde tussen de twee zoekopdrachten om te voorkomen dat ik een oneerlijk voordeel zou geven vanwege db-caching.
Epoche/unix-tijd doorlopen
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
(Merk op dat dit timestamptz oplevert zelfs als u een tijdzone gebruikt die u niet kent van het gegevenstype)
Resultaten
- Voer 1 uit :39,368 seconden
- Ren 3 :39.526 seconden
- Ren 5 :39.883 seconden
Datum_trunc en date_part gebruiken
SELECT
date_trunc('hour', ht.time)
+ date_part('minute', ht.time)::int / 5 * interval '5 min'
FROM huge_table AS ht LIMIT 4000000
Resultaten
- Loop 2 :34,189 seconden
- Loop 4 :37,028 seconden
- Ren 6 :32,397 seconden
Systeem
- DB-versie:PostgreSQL 9.6.2 op x86_64-pc-linux-gnu, gecompileerd door gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, 64-bits
- Kern:Intel® Xeon®, E5-1650v2, Hexa-Core
- RAM:64 GB, DDR3 ECC-RAM
Conclusie
Jouw versie lijkt sneller te zijn. Maar niet snel genoeg voor mijn specifieke gebruik. Het voordeel dat u het uur niet hoeft te specificeren, maakt de epoch-versie veelzijdiger en produceert eenvoudiger parametrering in client-side code. Het behandelt 2 hour intervallen net zo goed als 5 minute intervallen zonder de date_trunc tijdseenheid argument omhoog. Tot slot, ik wou dat dit tijdseenheidargument in plaats daarvan werd veranderd in een tijdsintervalargument.