> or disabling index scans in this case
replyThis seems rather extreme. The pathological case only seems to make a given timestamp ~1h bigger, so you could still use an index scan, just with a bigger input followed by a filter that removes the timestamps that shouldn't be in the query.
OT: Crazy that TZ-less are default in so many RDBMS. TZ included should be the default, and no-TZ opt in like TIMESTAMP NO TIME ZONE.
replyDrives me crazy that the engineers I work with are perfectly happy writing TZ-less datetime strings to the hundreds of tables we manage. Every user has to guess, or be informed, that they’re UTC.
replyIn cases where the data itself doesn't carry the unit (or TZ in this case), I usually ask that the unit-less columns at least include the unit in the name. A TZ-less column is not that bad if it is suffixed "UTC", e.g. `ExecutionTimeUtc`.
replyThere are probably real world cases where dropping the TZ/offset provides meaningful performance/storage savings, but it hasn't been the typical case in my current sector.
> Every user has to guess, or be informed, that they’re UTC.
replyAt least they are UTC and not EST or PST...
They must yearn for the before times when text could be in an encoding specified only as: "your guess is as good mine!"
reply