Cockroach handles the sharding, replicating, and rebalancing of data automatically and transparently to the end user, so the idea of operating within a “partition” or “shard” of data, while fairly accurate for what’s happening under the hood, may be a bit confusing, especially if you’re used to what that means with other RDBMS systems.
I’ve found it’s more helpful to think in terms of “ranges” of k/v pairs, rather than “shards” (and the documentation follows the same nomenclature). You’re correct however that your data in different tables will be stored in different ranges, and even data in the same table may be split amongst several ranges if the amount of data is large enough.
A good overview of Cockroach’s transactions can be found in this blog post - How CockroachDB Does Distributed, Atomic Transactions.
A big takeaway is that Cockroach is a mostly optimistic system. It doesn’t provide “locks” on tables or partitions, instead opting to notify at commit time if there is a conflict, and the client is responsible for retrying. There’s a lot of detail being skipped over there, including things like transaction priority and the write intent system but that’s the core takeaway for answering your question, if you don’t want to read that post.
In short, yes, multi-range (and single range) transactions are executed in parallel, and if there is no intersection in the data being affected, all should completely cleanly, without any locking or retrying. The system used to handle that is described in that blog