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

sql/row: use Put instead of CPut when updating value of secondary index #137805

Merged
merged 2 commits into from
Jan 15, 2025

Conversation

michae2
Copy link
Collaborator

@michae2 michae2 commented Dec 19, 2024

sql/row: use Put instead of CPut when updating value of secondary index

When an UPDATE statement changes the value but not the key of a secondary index (e.g. an update to the stored columns of a secondary index) we need to write a new version of the secondary index KV with the new value.

We were using a CPutAllowingIfNotExists to do this, which verified that if the KV existed, the expected value was the value before update. But there's no need for this verification. We have other mechanisms to detect a write-write conflict with any other transaction that could have changed the value concurrently. We can simply use a Put to overwrite the previous value.

This also matches what we do for the primary index when the PK doesn't change.

Epic: None

Release note: None


sql: change CPutAllowingIfNotExists with nil expValue to CPut

CPutAllowingIfNotExists with empty expValue is equivalent to CPut with empty expValue, so change a few spots to use regular CPut. This almost gets rid of CPutAllowingIfNotExists entirely, but there is at least one spot in backfill (introduced in #138707) that needs to allow for both a non-empty expValue and non-existence of the KV.

Also drop "(expecting does not exist)" from CPut tracing, as CPut with empty expValue is now overwhelmingly the most common use of CPut. And this matches the tracing in #138707.

Epic: None

Release note: None

This comment was marked as resolved.

@cockroach-teamcity
Copy link
Member

This change is Reviewable

@michae2 michae2 changed the title wip sql/row: use Put instead of CPut when updating value of secondary index Jan 10, 2025
@michae2 michae2 requested review from stevendanna, yuzefovich, arulajmani and a team January 10, 2025 22:19
@michae2 michae2 marked this pull request as ready for review January 10, 2025 22:19
@michae2 michae2 requested review from a team as code owners January 10, 2025 22:19
@michae2
Copy link
Collaborator Author

michae2 commented Jan 10, 2025

I think this is RFAL.

Copy link
Member

@yuzefovich yuzefovich left a comment

Choose a reason for hiding this comment

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

Nice! :lgtm:

Reviewed 2 of 2 files at r1, 7 of 7 files at r2, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @arulajmani, @michae2, and @stevendanna)


pkg/sql/opt/exec/execbuilder/testdata/secondary_index_column_families line 231 at r1 (raw file):


# Ensure that updates only touch the changed column families.
query T kvtrace(CPut,prefix=/Table/107/2/)

nit: let's update the directive to match the Put.

Copy link
Collaborator

@stevendanna stevendanna left a comment

Choose a reason for hiding this comment

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

Nice!

Comment on lines 428 to 435
if traceKV {
k := keys.PrettyPrint(ru.Helper.secIndexValDirs[i], newEntry.Key)
v := newEntry.Value.PrettyPrint()
if expValue != nil {
log.VEventf(ctx, 2, "CPut %s -> %v (replacing %v, if exists)", k, v, oldEntry.Value.PrettyPrint())
if sameKey {
log.VEventf(ctx, 2, "Put %s -> %v", k, v)
} else {
log.VEventf(ctx, 2, "CPut %s -> %v (expecting does not exist)", k, v)
log.VEventf(ctx, 2, "CPut %s -> %v", k, v)
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Not for this PR, but if we ever do a cleanup pass of this function, it would be nice to re-organize things so the logging doesn't take up so much attention. Also of interest is that we log ForcePut's differently.

When an UPDATE statement changes the value but not the key of a
secondary index (e.g. an update to the stored columns of a secondary
index) we need to write a new version of the secondary index KV with the
new value.

We were using a CPutAllowingIfNotExists to do this, which verified that
if the KV existed, the expected value was the value before update. But
there's no need for this verification. We have other mechanisms to
detect a write-write conflict with any other transaction that could have
changed the value concurrently. We can simply use a Put to overwrite the
previous value.

This also matches what we do for the primary index when the PK doesn't
change.

Epic: None

Release note: None
@michae2
Copy link
Collaborator Author

michae2 commented Jan 14, 2025

TFTRs!

bors r=yuzefovich,stevendanna

@craig
Copy link
Contributor

craig bot commented Jan 14, 2025

Build failed (retrying...):

  • unit_tests

CPutAllowingIfNotExists with empty expValue is equivalent to CPut with
empty expValue, so change a few spots to use regular CPut. This almost
gets rid of CPutAllowingIfNotExists entirely, but there is at least one
spot in backfill (introduced in cockroachdb#138707) that needs to allow for both a
non-empty expValue and non-existence of the KV.

Also drop "(expecting does not exist)" from CPut tracing, as CPut with
empty expValue is now overwhelmingly the most common use of CPut. And
this matches the tracing in cockroachdb#138707.

Epic: None

Release note: None
@michae2
Copy link
Collaborator Author

michae2 commented Jan 15, 2025

Trying again...

bors r=yuzefovich,stevendanna

@craig craig bot merged commit f1a746c into cockroachdb:master Jan 15, 2025
21 of 22 checks passed
@michae2 michae2 deleted the secondary_put branch January 15, 2025 04:50
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.

4 participants