Closed jgaskins closed 1 year ago
One notable thing about this PR is that I didn't do anything with SET TIME ZONE
or SHOW TIME ZONE
. It's all being set in memory on the connection object. No idea if that's a good thing or a bad thing.
That's probably a good idea. I deal mainly with ephemeral infrastructure and sometimes forget that the environment can change around a running program. 🤔
I was trying to see what the performance penalty of decoding the TSTZ
with the Time::Location
is and it looks like it's about ~20µs of CPU time for 1k TSTZ
values, or 20ns each. Here's the benchmark I used, where the only difference is whether it executes time.in location
(the time calculation itself is identical between TS
and TSTZ
), fetching 1k time values from the DB on each query to amortize the latency cost:
➜ crystal-pg git:(decode-tstz-with-timezone) crystal run --release examples/bench_time_zone_check.cr
timestamptz 5.81k (172.01µs real, 77.47µs user, 5.83µs sys) (± 0.81%) 58.7kB/op 1.11× slower
timestamp 6.47k (154.62µs real, 55.48µs user, 7.01µs sys) (± 1.83%) 58.7kB/op fastest
Just got a chance actually dive in and explore this, thanks @jgaskins! I think everything makes sense. I'll add the cache clear method that @straight-shoota suggested and a changelog right now.
This is an idea for how #265 could be implemented, mostly implemented on my lunch break today. 🙃
Closes #265