Check unique indexes when enabling compression

[mkindahl]

When enabling compression on a table, there is a check of unique constraints and primary key constraints, but no check if there is just a unique index. This means that it is possible to create a compressed table without getting a warning that you should include the columns in the index into the segmentby field, which can lead to suboptimal query times.

This commit adds a check for the unique index as well and ensure that a similar warning is printed as for a unique constraint.

Fixes #5892

[github-actions]

@mahipv, @svenklemm: please review this pull request.

Powered by pull-review

[codecov]

Codecov Report

Merging #5894 (666a3fe) into main (61c288e) will decrease coverage by 8.09%.
The diff coverage is 85.18%.

❗ Current head 666a3fe differs from pull request most recent head 9489332. Consider uploading reports for the commit 9489332 to get more accurate results

@@            Coverage Diff             @@
##             main    #5894      +/-   ##
==========================================
- Coverage   87.08%   78.99%   -8.09%     
==========================================
  Files         239      239              
  Lines       55750    48863    -6887     
  Branches    12348    12244     -104     
==========================================
- Hits        48550    38600    -9950     
+ Misses       4872     4496     -376     
- Partials     2328     5767    +3439     

Files Changed	Coverage Δ
tsl/src/compression/create.c	86.50% <85.18%> (-7.55%)	⬇️

... and 219 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[sb230132]

Since we did not support UPDATE/DELETE on compressed hypertable, we had these checks to ensure columns mentioned in constraints match either segmentby or orderby columns when enabling compression.

Future plan is to remove all these checks.

[sb230132]

Why there is no warning for "time" column ?

[mkindahl]

Because the time column is implicitly added to the orderby:

	ownerid = ts_rel_get_owner(ht->main_table_relid);
	segmentby_cols = ts_compress_hypertable_parse_segment_by(with_clause_options, ht);
	orderby_cols = ts_compress_hypertable_parse_order_by(with_clause_options, ht);
>>	orderby_cols = add_time_to_order_by_if_not_included(orderby_cols, segmentby_cols, ht);

	if (TS_HYPERTABLE_HAS_COMPRESSION_ENABLED(ht))
		check_modify_compression_options(ht, with_clause_options, orderby_cols);

	compresscolinfo_init(&compress_cols, ht->main_table_relid, segmentby_cols, orderby_cols);

[nikkhils]

LGTM

[mkindahl]

Since we did not support UPDATE/DELETE on compressed hypertable, we had these checks to ensure columns mentioned in constraints match either segmentby or orderby columns when enabling compression.

Future plan is to remove all these checks.

I think these checks are good to have, but they should not be errors.

The reason why they are good to have is because if you pick the wrong column, you have to run a full decompression (in the current implementation) to figure out if there are any conflicts, but if you use the columns of the index as part of the segmentby columns, checking does not require decompression.

The reason they should not be errors is because it works anyway, it is just not very efficient.

[timescale-automation]

Automated backport to 2.11.x not done: cherry-pick failed.

Git status

HEAD detached at origin/2.11.x
You are currently cherry-picking commit ee2ddf889.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	new file:   .unreleased/bugfix_5892
	modified:   tsl/src/compression/create.c
	modified:   tsl/test/expected/compression_errors.out
	modified:   tsl/test/sql/compression_errors.sql

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   tsl/test/expected/compression.out

Job log