distsqlrun: include StartScan stall time in EXPLAIN ANALYZE #38329
Conversation
|
This change is |
There was a problem hiding this comment.
Reviewed 6 of 6 files at r1.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @asubiotto)
pkg/sql/distsqlrun/stats.go, line 138 at r1 (raw file):
} // Next() calls NextRow() on the underlying Fetcher. If the returned
[nit]: I'd adjust the wording of the second sentence since in ProducerMetadata only a single field can be set. I'd say something like "If an error is encountered, it is returned via a ProducerMetadata."
We previously assumed that StartScan was a once-per-query operation so would not include time spent there in total stall time. However, that is not the case for lookup joins, where the bulk of the work is performed in StartScan once per batch. Release note: None
There was a problem hiding this comment.
Reviewable status:
pkg/sql/distsqlrun/stats.go, line 138 at r1 (raw file):
Previously, yuzefovich wrote…
[nit]: I'd adjust the wording of the second sentence since in ProducerMetadata only a single field can be set. I'd say something like "If an error is encountered, it is returned via a ProducerMetadata."
Done.
|
bors r=yuzefovich |
38329: distsqlrun: include StartScan stall time in EXPLAIN ANALYZE r=yuzefovich a=asubiotto We previously assumed that StartScan was a once-per-query operation so would not include time spent there in total stall time. However, that is not the case for lookup joins, where the bulk of the work is performed in StartScan once per batch. Release note: None cc @jordanlewis Co-authored-by: Alfonso Subiotto Marqués <alfonso@cockroachlabs.com>
Build succeeded |
We previously assumed that StartScan was a once-per-query operation so
would not include time spent there in total stall time.
However, that is not the case for lookup joins, where the bulk of the
work is performed in StartScan once per batch.
Release note: None
cc @jordanlewis