filter_last predicate: bool

Keeps rows whose boolean predicate is true and drops all others while preserving the input schema (aside from optional internal “matching” metadata used by the UI).

You may write the predicate using ordinary boolean expressions (and, or, not, comparisons, functions, and column references). Analytic window expressions such as window(...) are allowed in the predicate when the surrounding pipeline makes them valid. You may also use field match syntax: column <op> <search expression>, where <op> is =, !=, ~, or !~. For = and !=, use value comparisons (including comparing two columns). Search-style expressions—quoted text, angle-bracket term lists with a column prefix, /regex/ patterns, or IPv4 CIDR literals—must be used only with ~ or !~, not with = or !=.

Search terms must appear in double quotes, single quotes, or angle brackets attached to a column (for example message ~ "error" or message ~ <timeout connection> meaning every listed term must match in that field). Do not rely on bare-word search terms.

On Resource datasets, filter_last always applies last-value semantics: each resource is either kept in full or removed entirely, according to whether its latest state in the query window satisfies the predicate. Resource handling for filter is described on that page and is not always identical to filter_last. On event, interval, and table inputs, filter_last matches filter for the same predicate.

When a Resource predicate reads time-varying (non-const) columns, the implementation evaluates those columns at each resource’s last value in the window before deciding inclusion; that path is not compatible with the same acceleration guarantees as a simple row filter. Predicates that reference only const columns on the resource avoid that rewrite. If a column should be treated as constant for filtering purposes, set_col_immutable may be appropriate.

For resource-scoped conditions over sliding or relative time ranges, ever is often a better fit than filtering alone.

Categories

• Filter

Accelerable

filter_last is sometimes accelerable, depending on options used. A dataset that only uses accelerable verbs can be accelerated, making queries on the dataset respond faster.

Examples

filter_last month_number > 6

Keeps July and August after June using a simple numeric comparison on month_number, same as filter on a non-Resource table.

filter_last not month_number = 1

Excludes January by negating an equality test, illustrating boolean not in the filter_last predicate.

filter_last string(month_name) ~ "May"

Uses a quoted search term with ~ so the string field must contain the substring "May"; search terms must be quoted or angle-bracketed, not bare words.