The world's fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.
Hi team, I noticed that StarRocks gets VERY slow when I use RFC3339 datetime values (e.g. 2024-07-03T00:00:00Z) to filter partitions.
The examples below are not affected by cache or cold-starts.
SELECT COUNT(1)
FROM legacy.performance
WHERE mm_date >= '2024-07-01T00:00:00Z'
AND mm_date < '2024-07-03T00:00:00Z'
[2024-07-25 11:01:39] 1 row retrieved starting from 1 in 35 s 93 ms (execution: 35 s 48 ms, fetching: 45 ms)
> SELECT COUNT(1)
FROM legacy.performance
WHERE mm_date >= '2024-07-01T00:00:00'
AND mm_date < '2024-07-03T00:00:00'
[2024-07-25 11:01:42] 1 row retrieved starting from 1 in 760 ms (execution: 734 ms, fetching: 26 ms)
> SELECT COUNT(1)
FROM legacy.performance
WHERE mm_date >= '2024-07-01 00:00:00'
AND mm_date < '2024-07-03 00:00:00'
[2024-07-25 11:01:46] 1 row retrieved starting from 1 in 864 ms (execution: 827 ms, fetching: 37 ms)
Hi team, I noticed that StarRocks gets VERY slow when I use RFC3339 datetime values (e.g. 2024-07-03T00:00:00Z) to filter partitions.
The examples below are not affected by cache or cold-starts.
Query plan - slow query:
Query plan - fast queries:
StarRocks version: 3.3.1-2b87854 - Shared Data