2 things in CI:

• Multiple checksum reports (https://clickhouse-test-reports.s3.yandex.net/27080/f2f778376295c077224fcd6f9242f6f0164a4e5f/functional_stateful_tests_(address).html#fail1): it looks like a hardware issue as I've built ASAN locally and run those tests without issues. The odd thing is that they are connection to localhost, maybe memory?
• PVS check. I'll try to fix it

Let's see if a new commit fixing (2) also shows the address issues or it has been something temporary.

for example Liberia used to be -0:43:08

That's interesting...

Rebased with master. No new changes (it was clean already)

We have 2x performance degradation of toSecond function or somewhat similar:
https://clickhouse-test-reports.s3.yandex.net/27080/1b58e276b8b0534e925c79e9764896c847f9ec7f/performance_comparison/report.html#fail1

We have 2x performance degradation of toSecond function or somewhat similar:

It might be because Asia/Kolkata is at UTC+5:30 and that won't use the fast path (offset_is_whole_number_of_hours_during_epoch). I'll see if there is something better to do in this situation,

I'm not sure about this change.
We did not support non whole 15 minutes offsets - this is deliberate choice.

... but if we can avoid any performance degradation.

I think the performance degradation can be solved in a similar way as the whole hour thing, by adding another flag like offset_is_whole_number_of_minutes_during_epoch. It's not great, but it should limit the performance impact to the offsets were the responses were wrong. I'll give it a try (likely on Monday).

Ok, sounds good.

Rebased and applied the improvements from the comments.

Performance of the affected query:

• Initially (before changes): QPS: 12.465, RPS: 623806343.190, MiB/s: 4759.265, result RPS: 12.465
• After initial changes: QPS: 3.516, RPS: 175981641.031, MiB/s: 1342.633, result RPS: 3.516
• Now: QPS: 12.487, RPS: 624930109.263, MiB/s: 4767.838, result RPS: 12.487

Looking at how things work internally (DateTimeTransforms.h), it looks like the fast path (common offsets) of some of the functions (toSecond, toMinute) could be vectorized using the same architecture as other functions (accepting an array instead of a single element), but that's something for a different time.

Ok.

Theoretically it can also be auto-vectorized, because the function is inlined. But it depends if compiler will be able to move "unlikely" branch check out of the loop.

I added an invalid optimization (ok for minutes, not for hours). I'm looking into it and will try to unify calls/code if possible. Sadly, changing DateLutImpl.h requires recompiling ~1300 files so it takes time to verify and benchmark

GithubException: 500 null

Looks like GitHub API is down.

@Mergifyio update

Command update: success

Branch has been successfully updated

@Mergifyio update

Command update: success

Branch has been successfully updated