workload/tpcc: improve indexing to permit better partitioning

[nvanbenschoten]

This PR contains a number of incremental improvements to TPC-C that allow it to be more effectively partitioned. The changes focus on migrating indexes to all be partitionable by warehouse and removing indexes that are only needed for foreign keys when fks are not enabled. This is all a precursor to a follow-up PR: #36855.

I'm assigning @jordanlewis and @danhhz as reviewers because between the two of you most of the changes here have already been agreed upon.

This PR will require me to regenerate all TPC-C fixtures. I intend to do so before it is merged.

[cockroach-teamcity]

This change is 

[danhhz]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @danhhz, @jordanlewis, and @nvanbenschoten)

---

pkg/workload/tpcc/ddls.go, line 88 at r6 (raw file):

	// HISTORY table.
	tpccHistorySchemaBase = `(
		rowid    uuid    not null default gen_random_uuid(),

While you're going to generate fixtures, I'd love to reconfirm that we think this field should be a UUID. I dug up the PR (#23827) that went from implicit PK to UUID and the reasoning for UUID over unique_rowid was that 1) unique_rowid apparently generated a duplicate (!) and 2) our production recommendation is UUID. I think we could fix (1), (2) is more compelling to me.

I ask because UUIDs make this table the only one in our tpcc Generator that doesn't generate rows in PKs order, which makes our lives harder for the upcoming direct-ingest IMPORT. It's something we'll have to solve for secondary indexes, but "solve" here means something like backpressure and trying to be careful about compactions and it's definitely better if the generated data doesn't overlap in the first place. It may also be possible to switch the UUIDs in the initial data to be deterministically generated from batchIdx and the offset within the batch, but I haven't looked into this yet.

Does anyone have strong opinions here?

---

pkg/workload/tpcc/tpcc.go, line 390 at r6 (raw file):

		Splits: splits(workload.BatchedTuples{
			NumBatches: numBatches(w.warehouses, numWarehousesPerRange),
			NumTotal:   w.warehouses,

all of these NumTotals on the splits look wrong to me. They're supposed to represent how many total rows are produced by all the batches, but each batch seems to be of size 1. I'm actually planning on getting rid of them entirely, they haven't been useful for anything, so I'd omit them here

[nvanbenschoten]

Easiest way to address Dan's comment: wait until he does himself in other PRs 😃 TFTR!

bors r+

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @danhhz and @jordanlewis)

---

pkg/workload/tpcc/ddls.go, line 88 at r6 (raw file):

Previously, danhhz (Daniel Harrison) wrote…

While you're going to generate fixtures, I'd love to reconfirm that we think this field should be a UUID. I dug up the PR (#23827) that went from implicit PK to UUID and the reasoning for UUID over unique_rowid was that 1) unique_rowid apparently generated a duplicate (!) and 2) our production recommendation is UUID. I think we could fix (1), (2) is more compelling to me.

I ask because UUIDs make this table the only one in our tpcc Generator that doesn't generate rows in PKs order, which makes our lives harder for the upcoming direct-ingest IMPORT. It's something we'll have to solve for secondary indexes, but "solve" here means something like backpressure and trying to be careful about compactions and it's definitely better if the generated data doesn't overlap in the first place. It may also be possible to switch the UUIDs in the initial data to be deterministically generated from batchIdx and the offset within the batch, but I haven't looked into this yet.

Does anyone have strong opinions here?

You're way ahead of me: #37515.

---

pkg/workload/tpcc/tpcc.go, line 390 at r6 (raw file):

Previously, danhhz (Daniel Harrison) wrote…

all of these NumTotals on the splits look wrong to me. They're supposed to represent how many total rows are produced by all the batches, but each batch seems to be of size 1. I'm actually planning on getting rid of them entirely, they haven't been useful for anything, so I'd omit them here

Looks like you got rid of them all.

[craig]

Build succeeded

• GitHub CI (Cockroach)