Large tables
Filter with indexes first, then cap spend.
Every row that reaches jev() is sent to the API. On a large table, shrink that set in SQL before the model runs.
SELECT * FROM tickets
WHERE created_at >= CURRENT_DATE - 7
AND status = 'open'
AND jev(tickets, 'the customer is angry');The table is streamed in physical order and judged as it goes, so memory does not grow with table size. Rows that cheaper predicates reject before jev() runs are skipped, not judged, and a LIMIT stops the read-ahead after the in-flight window. See How it works for the pipeline.
Spend guards abort a statement that would send too much. They default to off (0):
SET jev.max_rows_per_statement = 2000;
SET jev.max_chars_per_statement = 500000;max_rows_per_statement counts rows headed to the API. max_chars_per_statement counts characters of row data. Both are GUCs; the full list is on Settings.
A view that keeps only the columns the condition needs also cuts tokens. That pattern is in Combining with SQL.