Geïnspireerd door de opmerking van @Frank heb ik een aantal tests uitgevoerd en mijn vraag daarop aangepast. Dit moet 1) correct en 2) zo snel mogelijk zijn:
SELECT u.login, u.id, u.first_name
FROM pref_users u
WHERE u.login > u.logout
AND u.login >= now()::date + interval '1h'
ORDER BY u.login;
Aangezien er geen toekomstige tijdstempels in uw tabel staan (ik neem aan), heeft u geen bovengrens nodig.date_trunc('day', now())
is bijna hetzelfde als now()::date
(of enkele andere alternatieven die hieronder worden beschreven), alleen dat het timestamp
. teruggeeft in plaats van een date
. Beide resulteren in een timestamp
hoe dan ook na het toevoegen van een interval
.
Onderstaande uitdrukkingen presteren iets anders. Ze geven subtiel verschillende resultaten omdat localtimestamp
retourneert gegevenstype timestamp
terwijl now()
retourneert timestamp with time zone
. Maar wanneer gecast naar date
, beide worden geconverteerd naar dezelfde lokale datum en een timestamp [without time zone]
wordt verondersteld zich ook in de lokale tijdzone te bevinden. Dus in vergelijking met de corresponderende timestamp with time zone
ze resulteren allemaal intern in hetzelfde UTC-tijdstempel. Meer details over het omgaan met tijdzones in deze gerelateerde vraag.
Beste van vijf. Getest met PostgreSQL 9.0. Herhaald met 9.1.5:consistente resultaten binnen een foutmarge van 1%.
SELECT localtimestamp::date + interval '1h' -- Total runtime: 351.688 ms
, current_date + interval '1h' -- Total runtime: 338.975 ms
, date_trunc('day', now()) + interval '1h' -- Total runtime: 333.032 ms
, now()::date + interval '1h' -- Total runtime: 278.269 ms
FROM generate_series (1, 100000)
now()::date
is duidelijk iets sneller dan CURRENT_DATE
.