Skip to content

Compare timestamps with a <= b + INTERVAL instead of (a - b) <= INTERVAL - #8

Closed
mbutrovich wants to merge 2 commits into
dbolympics:mainfrom
mbutrovich:interval-addition-form
Closed

mbutrovich wants to merge 2 commits into
dbolympics:mainfrom
mbutrovich:interval-addition-form

Conversation

@mbutrovich

@mbutrovich mbutrovich commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

This proposes a change to nine queries based on rule 3 of DIALECTS.md, which gives (t - x) > interval '30 days' to x < t - INTERVAL '30' DAY as the canonical form. q114 already has it. I found the other nine sites (q086, q233, q237, q274, q288, q304, q350, q404, q408) while debugging DataFusion errors. They come from a real DataFusion bug, apache/datafusion#26671. This change brings the queries into line with DIALECTS.md and also works around that failure.

The PR adds one edits.json entry per site and regenerates with tools/canonical.py. numerics.json changes only where its replacement text contains one of these predicates.

Tests are the SF1 results of all nine queries, which match workload/results/sf1/through-2025-Q4 with dbo-bench check on DuckDB 2.0.0 (integer_division on) and DataFusion 55.0.0. With the year_month change from #7 applied, DataFusion SF1 mismatches go from 12 to 5. The new form returns the same values as the old one on PostgreSQL and Umbra, checked on a small table with boundary and NULL rows. Hyper, CedarDB, Firebolt and ClickHouse were not run.

@alamb

alamb commented Oct 23, 2026

Copy link
Copy Markdown
Contributor

The description of this PR is sort of hard to parse I think, so I would like to try a summary:

There is a real DataFusion bug comparing certain types of intervals that is exposed in the benchmark. The bug is tracked by this ticket (and we will fix)

This PR proposes a workaround to the DataFusion runner using a syntax that computes the correct quantity

@mbutrovich

Copy link
Copy Markdown
Contributor Author

There is a real DataFusion bug comparing certain types of intervals that is exposed in the benchmark. [...]

This PR proposes a workaround to the DataFusion runner using a syntax that computes the correct quantity

Thanks, I rewrote the description. This PR is not a DataFusion workaround. It proposes a change to the canonical text of nine queries based on rule 3, and I found the sites while debugging DataFusion errors. Those errors come from a real DataFusion bug (apache/datafusion#26671). The change brings the queries into line with DIALECTS.md and also works around that failure.

@alamb

alamb commented Oct 23, 2026

Copy link
Copy Markdown
Contributor

q114 already has it. I found the other nine sites (q086, q233, q237, q274, q288, q304, q350, q404, q408) while debugging DataFusion errors

Here is the actual query. q114 uses ts1 < INTERVAL .. + ts2 syntax:

and occurred_at < TIMESTAMP '2026-01-05' - INTERVAL '30' DAY

Here is an example of the other syntax (in q086) of (ts1 - ts2) < INTERVAL ..:

CASE WHEN (s.delivered_at - s.shipped_at) <= INTERVAL '7 days' THEN 'on-time' ELSE 'late' END AS delivery_bucket,

@toschmidt

Copy link
Copy Markdown
Contributor

@mbutrovich, thanks for finding this. We will look into it!

@hbirler

hbirler commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

Timestamps have been a big source of pain in cleaning up the queries and this rewrite seems like a great fix. I just checked that it works on PostgreSQL and MySQL, so it passes the criteria. The previous version only worked on PostgreSQL so this is a definite improvement.

The real standard way of doing datetime subtraction is like (a - b) DAY (which first truncates inputs before subtracting) or (a - b) DAY TO SECOND:

<interval value expression> ::=
    <left paren> <datetime value expression> <minus sign> <datetime term> <right paren> <interval qualifier>

But from what I know, most databases don't support this. So your suggestion is the best option we have right now.

@toschmidt

Copy link
Copy Markdown
Contributor

merged, thanks @mbutrovich

@toschmidt toschmidt closed this Oct 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants