Summary
ASAP selects precompute windows over a half-open [start, end) interval, while ClickHouse's BETWEEN A AND B is inclusive-inclusive (>= A AND <= B). For a DATEADD(s,-1,T) .. T span this makes the two systems answer different questions (different GROUP BY cardinality and aggregates), so latency/fidelity comparisons aren't meaningful.
Rather than change ASAP's window semantics, add SQL support for the half-open form:
WHERE time >= A AND time < B
ClickHouse executes >=/< as a true half-open [A, B) scan — the same interval ASAP already uses — so a query written this way is semantically equivalent on both backends and can be used directly for benchmarking.
Scope
Extend the SQL time-clause parser (sqlpattern_parser.rs::get_time_info) to accept a conjunction of two comparisons on the time column, in addition to the existing BETWEEN.
Strict operator policy: accept only >= (lower bound) + < (upper bound). Reject > / <= combinations so there is never a silent off-by-one against the ClickHouse baseline; rejected/unmatched queries follow the existing unsupported-query path (forwarded to ClickHouse when forward_unsupported_queries: true, otherwise 501).
Support either operand order (time >= A AND time < B or reversed) and the time column on either side of each comparison (A <= time AND B > time).
No changes to TimeInfo, engine timestamp math, the store containment predicate, or the pattern matcher — the half-open form maps onto the existing (start, duration) model, so BETWEEN continues to work unchanged.
Harden get_timestamp_from_between_highlow to return None on unrecognized time syntax instead of panicking.
Acceptance Criteria
WHERE time >= DATEADD(s,-11,NOW()) AND time < DATEADD(s,-10,NOW()) parses and produces the same execution context (window timestamps + aggregation) as the equivalent BETWEEN.- The same query runs end-to-end against both the ASAP ClickHouse adapter and the ClickHouse baseline.
> / <= combinations are treated as unmatched (not silently half-open).- Existing
BETWEEN behavior and all current tests remain green.
Summary
ASAP selects precompute windows over a half-open
[start, end)interval, while ClickHouse'sBETWEEN A AND Bis inclusive-inclusive (>= A AND <= B). For aDATEADD(s,-1,T) .. Tspan this makes the two systems answer different questions (differentGROUP BYcardinality and aggregates), so latency/fidelity comparisons aren't meaningful.Rather than change ASAP's window semantics, add SQL support for the half-open form:
ClickHouse executes
>=/<as a true half-open[A, B)scan — the same interval ASAP already uses — so a query written this way is semantically equivalent on both backends and can be used directly for benchmarking.Scope
Extend the SQL time-clause parser (
sqlpattern_parser.rs::get_time_info) to accept a conjunction of two comparisons on the time column, in addition to the existingBETWEEN.Strict operator policy: accept only
>=(lower bound) +<(upper bound). Reject>/<=combinations so there is never a silent off-by-one against the ClickHouse baseline; rejected/unmatched queries follow the existing unsupported-query path (forwarded to ClickHouse whenforward_unsupported_queries: true, otherwise501).Support either operand order (
time >= A AND time < Bor reversed) and the time column on either side of each comparison (A <= time AND B > time).No changes to
TimeInfo, engine timestamp math, the store containment predicate, or the pattern matcher — the half-open form maps onto the existing(start, duration)model, soBETWEENcontinues to work unchanged.Harden
get_timestamp_from_between_highlowto returnNoneon unrecognized time syntax instead of panicking.Acceptance Criteria
WHERE time >= DATEADD(s,-11,NOW()) AND time < DATEADD(s,-10,NOW())parses and produces the same execution context (window timestamps + aggregation) as the equivalentBETWEEN.>/<=combinations are treated as unmatched (not silently half-open).BETWEENbehavior and all current tests remain green.