Added regression test for issue 3083

[Hydrocharged]

This is for the following issue:

• CREATE INDEX ... WHERE (partial index) on a non-empty table fails: unable to find field with index N in row of N columns #3083

This appears to have been fixed already, so this is just adding a test for regression purposes.

[github-actions]

	Main	PR
Total	42090	42090
Successful	19854	19855
Failures	22236	22235
Partial Successes1	5440	5440

	Main	PR
Successful	47.1703%	47.1727%
Failures	52.8297%	52.8273%

${\color{lightgreen}Progressions (1)}$

subselect

QUERY: select count(*) from tenk1 t
where (exists(select 1 from tenk1 k where k.unique1 = t.unique2) or ten < 0);

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩

[itoqa]

Commit: 1c93fee: 5 test cases ran, 5 passed ✅.

Summary

Coverage focuses on database behavior for filtered indexes across creation on existing data, matching and nonmatching rows, uniqueness enforcement, row updates that change membership, and filtered versus unfiltered queries. It exercises normal flows plus boundary and conflict cases, with all covered behaviors operating as expected.

Safe to merge — the covered database behaviors passed without regressions or PR-attributable failures, so there is no identified merge blocker from this run.

Tests run by Ito

Result	Severity	Type	Description
✅	—	General	The database accepted duplicate keys while their rows were outside the filter, then rejected the duplicate when one row entered the filtered set. The final query returned only the two rows that matched the filter.
✅	—	Index	Partial indexes were created on tables that already had rows. Rows outside the filter stayed out of the results, and a later matching row appeared correctly.
✅	—	Rev	The unique partial index was created over existing data. Active rows were returned, an active duplicate was rejected, and an inactive duplicate was accepted.
✅	—	Rev	Changing a row to active made it visible through the partial index. Changing it back allowed another active row with the same key, and reactivating the original row was rejected while that key was in use.
✅	—	Rev	Queries that include the active-row filter used the partial index and returned ids 1 and 3. The same key range without that filter used the full table and returned ids 1 through 4, including inactive rows.

Tip

Reply with @itoqa to send us feedback on this test run.

[coffeegoddd]

@Hydrocharged DOLT

read_tests	from_latency	to_latency	percent_change
covering_index_scan_postgres	2.43	2.43	0.0
groupby_scan_postgres	78.6	80.03	1.82
index_join_postgres	2.22	2.22	0.0
index_join_scan_postgres	1.61	1.61	0.0
index_scan_postgres	458.96	467.3	1.82
oltp_point_select	0.37	0.36	-2.7
oltp_read_only	6.43	6.32	-1.71
select_random_points	0.72	0.72	0.0
select_random_ranges	1.04	1.03	-0.96
table_scan_postgres	467.3	467.3	0.0
types_table_scan_postgres	1170.65	1170.65	0.0

write_tests	from_latency	to_latency	percent_change
oltp_delete_insert_postgres	6.67	6.67	0.0
oltp_insert	3.36	3.36	0.0
oltp_read_write	13.46	13.46	0.0
oltp_update_index	3.55	3.55	0.0
oltp_update_non_index	3.25	3.25	0.0
oltp_write_only	6.91	7.04	1.88
types_delete_insert_postgres	7.17	7.17	0.0