A (hopefully) complete list of table schema we cannot support:
No hash sharded index
No partial Indexes
If a table contains a virtual computed column, we cannot support:
A secondary index whose key contains the computed column
A secondary index with a storing computed column (see). Note, if the computed column is stored in the pk, we can support the above.
The immediate mode write path does not understand how to evaluate expressions. The writer we currently use simply expects the full set of columns to be given to, even the computed ones, along with a list of columns that we've already determined should be updated. Note: we could, in theory, support these on the validated mode write path, but if we did, the schema change validation logic below would need to know which Job is in immediate mode vs validated mode. So to simplify schema change validation in 24.3, we should disallow these class of schema all together in LDR.
Computed column example: consider a table with two integer columns v1 and v2 and a third virtual column v3 defined as v1 and v2. If you created a secondary index on the virtual column v3, then suddenly you need to evaluate the expression v1 + v2 in order to create the index entry for v3. If the virtual column happens to be STORED then we could support it because then we will see the result of the source-side evaluation in the stored column that appears on the rangefeed.
Partial index example: When you have a partial index, you have to evaluate the expression to see if that index should be updated. For instance, you might have an index CREATE INDEX ON t (a, b) WHERE c > 5; that requires you to check if c is greater than 5 before you create in index entry for it.
A (hopefully) complete list of table schema we cannot support:
The immediate mode write path does not understand how to evaluate expressions. The writer we currently use simply expects the full set of columns to be given to, even the computed ones, along with a list of columns that we've already determined should be updated. Note: we could, in theory, support these on the validated mode write path, but if we did, the schema change validation logic below would need to know which Job is in immediate mode vs validated mode. So to simplify schema change validation in 24.3, we should disallow these class of schema all together in LDR.
Computed column example: consider a table with two integer columns v1 and v2 and a third virtual column v3 defined as v1 and v2. If you created a secondary index on the virtual column v3, then suddenly you need to evaluate the expression
v1 + v2
in order to create the index entry for v3. If the virtual column happens to beSTORED
then we could support it because then we will see the result of the source-side evaluation in the stored column that appears on the rangefeed.Partial index example: When you have a partial index, you have to evaluate the expression to see if that index should be updated. For instance, you might have an index
CREATE INDEX ON t (a, b) WHERE c > 5;
that requires you to check if c is greater than 5 before you create in index entry for it.Jira issue: CRDB-43687