pub struct VirtualConstraint {
pub spec: ConstraintSpec,
pub value: BoundExpr,
pub predicate: BoundExpr,
pub in_list: Vec<BoundExpr>,
}Expand description
One predicate offered to a module, with what it was made of.
The predicate is kept whole beside the constraint because the compiler may have to test it after all: a module that used the constraint without promising to apply it leaves the engine responsible for the answer.
Fields§
§spec: ConstraintSpecThe constraint as the module is shown it.
value: BoundExprThe value on the other side, which becomes an argument to filter.
predicate: BoundExprThe whole predicate, for the compiler to re-test when it must.
in_list: Vec<BoundExpr>The values of column IN (a, b, c), when that is what this constraint
came from, and empty otherwise.
An IN list is offered as =, and the engine runs the module’s
filter once for each distinct value, which is what SQLite does for a
virtual table. Before it was offered at all, DELETE FROM docs WHERE rowid IN (...) on an inillucent_search table read every row of the table and
tested each one against the whole list: 4.94 s to delete 2,000 rows of
120,000, where deleting them one statement at a time took a fraction of a
second. value holds the first item, so a module asked about the
constraint sees an ordinary =. The scan, not the statement, tests the
list, and skips the test when the module was run once per value and
promised omit, as SQLite does: generate_series(1) WHERE stop IN ('3')
stops at the integer 3.