Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
sql: emit point deletes during delete fastpath
Previously, the "deleteRange" SQL operator, which is meant to be a fast-path for cases in which an entire range of keys can be deleted, always did what it said: emitted DeleteRange KV operations. This precludes a crucial optimization: sending point deletes when the list of deleted keys is exactly known. For example, a query like `DELETE FROM kv WHERE k = 10000` uses the "fast path" delete, since it has a contiguous set of keys to delete, and it doesn't need to know the values that were deleted. But, in this case, the performance is actually worse if we use a DeleteRange KV operation for various reasons (see #53939), because: - ranged KV writes (DeleteRangeRequest) cannot be pipelined because an enumeration of the intents that they will leave cannot be known ahead of time. They must therefore perform evaluation and replication synchronously. - ranged KV writes (DeleteRangeRequest) result in ranged intent resolution, which is less efficient, especially until we re-enable time-bound iterators. The reason we couldn't previously emit point deletes in this case is that SQL needs to know whether it deleted something or not. This means we can't do a "blind put" of a deletion: we need to actually understand whether there was something that we were "overwriting" with our delete. This commit adds an optional "return key" parameter to DelRequest, which returns true if a value was actually deleted. Additionally, the deleteRange SQL operator detects when it can emit single-key deletes, and does so. Release note (performance improvement): point deletes in SQL are now more efficient during concurrent workloads.
- Loading branch information