You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Resolve simple OpenSearch date-math values at plan time in visitSearch
The Lucene-secondary engine on a composite parquet/lucene shard does not
evaluate date-math tokens like {@code now} or {@code now-1h} inside a
{@code query_string} filter, so the previous fallback path returned zero
rows for every {@code earliest=}/{@code latest=} predicate the visitor
left in query_string form.
Resolve the subset we can handle without snap-to-unit math at plan time:
- {@code "now"} / {@code "now()"} → current UTC instant
- {@code "now+/-Nunit"} (units {@code s m h d w M y q}) → simple arithmetic
- 12+-digit numeric strings → epoch-millis (PPL pre-converts
{@code earliest=1754020060.123} / {@code latest=1754020061} to ms
strings in {@code visitTimeModifierValue})
Emit the result as a {@code TIMESTAMP} literal so the comparison lowers
natively via DataFusion against the parquet primary, bypassing Lucene
entirely. Anchored expressions ({@code "2024-01-15||+1d"}),
snap-to-unit rounding ({@code "now/h"}, {@code "now+1mon/q"}), week
alignment ({@code "now/w-1d"}), and other shapes we don't model still
fall through to the existing {@code query_string} fallback.
Surfaced by `CalciteSearchCommandIT.testSearchWithAbsoluteEarliestAndNow`
and similar time-modifier tests in the analytics-engine route.
Signed-off-by: Kai Huang <ahkcs@amazon.com>
0 commit comments