forked from cockroachdb/cockroach
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
105256: sql: adjust DistSQL physical planning in multi-tenant mode r=yuzefovich a=yuzefovich This commit removes the logic that might reassign some spans to the gateway that can be applied in the multi-tenant deployment mode. This logic was introduced in cockroachdb#80353 with the following [rationale](cockroachdb#80353 (review)): ``` This will probably go away once we support locality-aware distribution, at least in this form. There's two reasons why I did this right now: 1. It avoids an extra hop (KV->assignee->gateway->client vs KV->gateway->client), and this is an optimization we sometimes do in the non-MT code path though at a later stage, 2. It makes the assignments and distribution type deterministic in testing when we expect to assign to only a single pod. ``` Since then the locality-aware planning has been implemented (addressing first half of point 1.). Also, the second half of point 1. applies both to single-tenant and multi-tenant modes (`maybeMoveSingleFlowToGateway`). Point 2. is a bit unfortunate and I'm not sure what to do about it yet (we'll need to figure it out if we ever make separate-process multi-tenant the default mode for running tests that check DistSQL planning). For now only a single test needed an adjustment to make it deterministic. Additionally, running TPCH queries experimentally has shown that this reassigning of single TableReader can make the query latency significantly different (sometimes reduce it, sometimes increase it) (see [here](cockroachdb#104379 (comment))). All of these reasons suggest that we should just get rid off this logic to unify the DistSQL physical planner more between single-tenant and multi-tenant modes. Addresses: cockroachdb#104379. Epic: CRDB-26687 Release note: None 105569: roachtest: harden and extend cancel roachtest r=yuzefovich a=yuzefovich This commit hardens `cancel` roachtest. In particular, this test involves two goroutines: the runner that is executing longer running TPCH query and the main goroutine that cancels that query. Previously, in order to ensure that the main goroutine attempts to cancel the query at the right moment, we slept for 250ms. Then, we would cancel all running non-internal queries other than `SHOW CLUSTER QUERIES` itself. This was problematic for a couple of reasons: - the TPCH query might not have started yet (due some Go scheduling delays) - we could actually try to cancel one of the setup queries (the runner does `USE tpch;` and `SET distsql = off;` before running the TPCH query). In order to address the first reason, this commit adjusts the runner to notify the main goroutine only after the setup queries are done and introduces the polling loop to wait until the TPCH query shows up. That polling loop will now randomly sleep for a random duration up to 1000ms (in order to improve the test coverage of both the optimizer and the execution engine). Note that we only check that the cancellation occurred within 3s (used to be 5s before this commit), so we don't sufficiently exercise the optimizer cancellation (which isn't the primary goal of this test anyway). The second reason is addressed by blocking the main goroutine until the setup queries are done. Fixes: cockroachdb#105528. Release note: None 105817: docs-issue-generation: add related PRs link to product change issue body r=nickvigilante a=nickvigilante Fixes DEVINF-447 Release note: None Co-authored-by: Yahor Yuzefovich <[email protected]> Co-authored-by: Nick Vigilante <[email protected]>
- Loading branch information
Showing
6 changed files
with
205 additions
and
131 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.