MCPcopy Index your code
hub / github.com/pingcap/tidb / optimizeDupKeyCheckForUpdate

Function optimizeDupKeyCheckForUpdate

pkg/executor/update.go:691–722  ·  view source on GitHub ↗

optimizeDupKeyCheckForUpdate trys to optimize the DupKeyCheckMode for an update statement. If the DupKeyCheckMode of the current statement can be optimized, it will return `DupKeyCheckLazy` to avoid the redundant requests to TiKV, otherwise, `DupKeyCheckInPlace` will be returned. The second argument

(txn kv.Transaction, ignoreNeedsCheckInPlace bool)

Source from the content-addressed store, hash-verified

689// redundant requests to TiKV, otherwise, `DupKeyCheckInPlace` will be returned.
690// The second argument `ignoreNeedsCheckInPlace` is true if `IGNORE` keyword is used in the update statement.
691func optimizeDupKeyCheckForUpdate(txn kv.Transaction, ignoreNeedsCheckInPlace bool) table.DupKeyCheckMode {
692 if txn.IsPipelined() {
693 // It means `@@tidb_dml_type='bulk'` which indicates to insert rows in "bulk" mode.
694 // At this time, `DupKeyCheckLazy` should be used to improve the performance.
695 // If "bulk" mode and IGNORE keyword are used together, "bulk" is prior, see:
696 // https://github.com/pingcap/tidb/issues/55187#issuecomment-2268356459
697 return table.DupKeyCheckLazy
698 }
699
700 if ignoreNeedsCheckInPlace {
701 // For `UPDATE IGNORE ...` and `INSERT IGNORE ... ON DUPLICATE KEY UPDATE ...` statements,
702 // `DupKeyCheckInPlace` should be used to make sure the executor can get the error
703 // immediately and ignore it then.
704 return table.DupKeyCheckInPlace
705 }
706
707 if txn.IsPessimistic() {
708 // We can just check duplicated key lazily without keys in storage for the below cases:
709 // - `txn.Pipelined()` is true.
710 // It means the user is using `@@tidb_dml_type="bulk"` to insert rows in bulk mode.
711 // DupKeyCheckLazy should be used to improve the performance.
712 // - The current transaction is pessimistic.
713 // The duplicate key check can be postponed to the lock stage.
714 // Please notice that for optimistic transaction, it always returns `DupKeyCheckInPlace` even if
715 // `tidb_constraint_check_in_place` is `OFF`.
716 // That is because `tidb_constraint_check_in_place` is only designed for insert cases, see comments in issue:
717 // https://github.com/pingcap/tidb/issues/54492#issuecomment-2229941881
718 return table.DupKeyCheckLazy
719 }
720
721 return table.DupKeyCheckInPlace
722}

Callers 2

updateRowsMethod · 0.85
batchUpdateDupRowsMethod · 0.85

Calls 2

IsPipelinedMethod · 0.65
IsPessimisticMethod · 0.65

Tested by

no test coverage detected