Currently TRUNCATE is using the newly added NodeDescStore.GetNodeDescriptorCount() function to calculate number of split points to retain: #93325.

@knz has provided a better solution:

The SQL layer has no business inspecting nodes and the number of nodes to do this computation.

There should be a new KV API that works as follows:

1. it accepts a list of "source" key spans, and another list of "destination" key spans as argument.
2. During TRUNCATE, the SQL layer would:
   • Create the new indexes for the table post-truncation
   • Pass the list of index key spans for the original table as "source" key spans to the new API
   • Pass the list of index key spans for the new (post-TRUNCATE) table as "destination" key spans
3. the KV API would internally enumerate all the split points for the source spans, and apply the same split points on the destination key spans, then scatter the result.

This way, at no point does the SQL layer need to issue manual splits / scatters any more.

Some more context https://reviewable.io/reviews/cockroachdb/cockroach/93325#-NJ7YmB51SJ-53TR25v-

Jira issue: CRDB-23116
Epic: CRDB-26067