Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHOENIX-7239: Fix issues when data and index have different salt buckets #1969

Closed
wants to merge 8 commits into from

Conversation

haridsv
Copy link
Contributor

@haridsv haridsv commented Sep 3, 2024

This PR includes the following changes:

  • Currently IndexMaintainer assumes that both data and index tables have the same number of salt buckets. This change adds a separate field for data table and uses it for constructing the data keys. This fixes the joins between uncovered index and data tables.
  • There is a typo in the CDC mutation code path that uses data table to construct the index row key instead of the index table which was throwing off the logic that join the changes to the data rows.
  • Test for time range queries has been rewritten to be simpler and also add coverage for the above special DF markers.
  • Some of the existing debug code in the CDC IT test has been refactored to be less repetitive.

@@ -470,6 +471,7 @@ private IndexMaintainer(final PTable dataTable, final PTable cdcTable, final PTa
this.immutableStorageScheme = index.getImmutableStorageScheme() == null ? ImmutableStorageScheme.ONE_CELL_PER_COLUMN : index.getImmutableStorageScheme();
this.dataEncodingScheme = dataTable.getEncodingScheme() == null ? QualifierEncodingScheme.NON_ENCODED_QUALIFIERS : dataTable.getEncodingScheme();
this.dataImmutableStorageScheme = dataTable.getImmutableStorageScheme() == null ? ImmutableStorageScheme.ONE_CELL_PER_COLUMN : dataTable.getImmutableStorageScheme();
this.nDataTableSaltBuckets = isDataTableSalted ? dataTable.getBucketNum() : PTable.NO_SALTING;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why are you introducing the special value of -1 ? The field nIndexSaltBuckets is set to 0 if index is not salted. We should maintain consistency.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the existing code, PTableImpl.toProto() translates 0 into -1 and PTableImpl.createFromProto() leaves this value as null by checking for -1. To be consistent, I think we should change nIndexSaltBuckets to also -1 instead of the other way around. I did a quick check, I think the existing code will work as is, as it checks for > 0. WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good @haridsv

@@ -1789,6 +1788,9 @@ public static IndexMaintainer fromProto(ServerCachingProtos.IndexMaintainer prot
} else {
maintainer.isCDCIndex = false;
}
if (proto.hasDataTableSaltBuckets()) {
maintainer.nDataTableSaltBuckets = proto.getDataTableSaltBuckets();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the proto doesn't have data table salt buckets then what is the nDataTableSaltBuckets field ? I think it will be 0 not -1. Seems like -1 is constant that is introduced is unnecessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree on the inconsistency, but I think it should be set to -1 to be consistent than 0 for the same reason I mentioned in the other thread.

@tkhurana
Copy link
Contributor

tkhurana commented Sep 19, 2024

@haridsv It would have been better if you only had salt bucket fix in this PR and not CDC related changes.

@haridsv haridsv closed this Sep 25, 2024
@haridsv haridsv reopened this Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants