lookup on(...), [columnbinding: expression]*

Enriches each input row with columns from a related dataset using a left-outer temporal join, while keeping the input dataset kind and the input’s valid-from and valid-to columns.

At least one trailing name:expression binding is required so the verb specifies which values to add. The target dataset must be a table, interval, or resource (not an event). When the input is a table, the target must be a resource or table. For table-to-resource lookups, values are taken from the latest resource state within the query window.

Predicate

Supply an on(...) boolean expression that references the target with @dataset.column paths. For equi-join conjuncts inside on(...), the columns on the target side must form a primary or candidate key on that dataset. You may instead follow a set_link with a ^linkLabel reference in the predicate position to reuse declared foreign-key paths.

Compared to join / leftjoin

Unlike join or leftjoin, lookup does not change the output kind to match the right-hand side and does not replace the left-hand time columns. If you need an event target or a full inner join, use join or leftjoin.

Grouping keys

If a binding overwrites a column that participates in the current grouping key, the output grouping key is cleared.

Categories

• Join

Accelerable

lookup is always accelerable if the input is accelerable. A dataset that only uses accelerable verbs can be accelerated, making queries on the dataset respond faster.

Examples

lookup on(station_id = @station.id), city:@station.city

Enrich event- or table-shaped readings with a resource field from station using on(...) and an explicit city binding pulled from the target.

set_link "stationLink", station_id=@station.id
lookup ^stationLink, city:@station.city

Reuse a declared link label so lookup applies the same foreign-key mapping as set_link without repeating the full on(...) predicate in the verb.