We added a --secondary-index flag to kv in #31573 to allow easy testing between workloads with and without secondary indexes. This works ok, but we've realized it's insufficient for complete benchmarking of secondary indexes. Here are a few reasons why:

1. it can only support a single secondary index
2. the secondary index contains the entire row, leading to it essentially doubling the storage cost
3. it's not realistic

We should create a new workload, and by extension a new roachtest, with knobs to specifically stress secondary index performance. Here's a proposed schema:

CREATE TABLE indexes (
    key  UUID PRIMARY KEY,
    col0 INT,
    col1 INT,
    col2 INT,
    col3 INT,
    col4 INT,
    col5 INT,
    col6 INT,
    col7 INT,
    col8 INT,
    col9 INT,
    data BYTES(64)
)

The workload could have a --indexes flag that defaults to zero and can be in the range [0, 10]. Depending on this value, we'll index that many col columns. Note that the data column will constitute about half the size of the row and will never be indexed.

This will give us the ability to slowly ramp up the number of secondary indexes on a table and observe how we scale along this dimension.

@robert-s-lee mentioned that a realistic workload for this would look something like:

Insert ( as the data has to be loaded first ), then update. With the update, want to make sure update of columns that do not have secondary indexes do not effect performance.