Function build_with 

pub fn build_with<'a>(
    plan: &'a Plan,
    catalog: &'a Catalog,
    cancel: &Cancel,
    memory: &Memory,
    seams: &Settings,
) -> Result<Query<'a>>

Builds the pipelines for a plan’s root, stoppable through this token and held to this budget.

The token is checked once per chunk by the driver, so the query stops at the first chunk boundary after the token says to. It is one check in one place rather than a decision per operator, because a decision per operator is a decision somebody gets wrong when they add the twentieth one. What the driver cannot see is work an operator does inside one call, and the join is the one that can: its nested loop runs to the end inside a single push, and a hundred thousand left rows against thirty thousand right ones is a minute with nothing looking at the token, so that loop holds the token as well and checks it once per left row.

The budget is not uniform, and that is the difference between the two. A streaming operator holds one chunk and gives it away again, so charging every operator would count the same megabyte once per level. Only the operators that buffer without bound take a reservation, and rudb_common::Memory lists which ones those are.

The measurement still happens. It goes into a report nobody reads, because the alternative is two builders that drift apart, and a pair of clock readings per chunk is not a cost worth avoiding by having a second one.

The seam settings are the session’s with the statement’s hints on top, and they are read here rather than looked up later, because a choice made while the query is built is a choice EXPLAIN can print before the query runs. An operator that sits on a seam chooses once, in its constructor, and holds what it chose.

Errors

The same as build.