You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
147853: sql,kv: reduce sets of writes included into LeafTxnInputState r=yuzefovich a=yuzefovich
This commit reduces the InFlightWrites and BufferedWrites sets that are
included in LeafTxnInputState to only those that overlap with the key
spans that will be read by the DistSQL processors. We now construct an
interval tree that contains all spans read by TableReaders and
TableID / IndexID specific key spans read by JoinReaders, InvertedJoiners,
and ZigzagJoiners, and all non-overlapping writes are not included into
the proto.
We skip constructing the reads tree if the txn hasn't performed any
writes (avoiding redundant work). We also introduce a session variable
that disables this optimization as an escape hatch.
All processors have been audited to fall into one of three categories:
- if a core might need to have access to the full write sets of the leaf
txn, it goes into the "unsafe" category;
- if a core is not on the "hot" query path (i.e. part of bulk operations,
etc), it goes into the "unoptimized" category;
- all other processors are examined more thoroughly in terms of what
operations the concrete spec might perform, and it's then decided between
"unsafe" and "safe".
Let's focus on the last category a bit more. There are two main ways
these processors worth optimizing can use the txn:
- explicitly, when fetching the data from disk (4 processor cores
mentioned above). (Note that vector search processors also use the txn
explicitly, but we currently put them into the first category since we
don't distribute plans with them.)
- implicitly, when evaluating some expression. All processor cores and
post-process specs that store `execinfrapb.Expression` are now checked
for being "unsafe".
Defining what expression is "unsafe" is a bit hand-wavy: if an
expression might use the txn somehow (e.g. it's a builtin function call),
then we deem it "unsafe".
LocalPlanNode gets special treatment too since an arbitrary planNode
might use the txn. This commit doesn't perform audit of those, so we
mark almost all cases as "unsafe".
Fixes: #139060.
Release note: None
Co-authored-by: Yahor Yuzefovich <[email protected]>
0 commit comments