Repository navigation
MDEV-41351 Allow a covering index scan for a SELECT ... FOR UPDATE un… - #5847
Conversation
|
|
2c6871c to
e55b836
Compare
e55b836 to
79d72cf
Compare
41cb62d to
399306e
Compare
e35e688 to
d75ffc7
Compare
dr-m
left a comment
dr-m
left a comment
There was a problem hiding this comment.
OK to push after addressing my comments. I am pleased to see that this eliminates some conditional branches from the lock_table() call in row_search_mvcc().
| @@ -16454,7 +16455,30 @@ int ha_innobase::extra_opt(enum ha_extra_function operation, ulong arg) | |||
| case HA_EXTRA_FULL_SCAN: | |||
| if (THDVAR(ha_thd(), table_lock_on_full_scan) && | |||
| !m_prebuilt->skip_locked && arg == ULONG_MAX) | |||
There was a problem hiding this comment.
The cheapest conditions should be evaluated first. On any modern ISA, the function parameters should reside in registers, so they should be tested first:
int ha_innobase::extra_opt(enum ha_extra_function operation, ulong arg)
{
switch (operation) {
case HA_EXTRA_FULL_SCAN:
if (arg == ULONG_MAX && !m_prebuilt->skip_locked &&
THDVAR(m_user_thd, table_lock_on_full_scan))Note: Our formatting does not deviate from K&R for the switch statement body.
Note 2: m_prebuilt would be zero-initialised in ha_innobase::ha_innobase() an initialised in ha_innobase::open(). At that point, also ha_innobase::update_thd() should be called, which is caching the value of ha_thd().
| if (THDVAR(ha_thd(), table_lock_on_full_scan) && | ||
| !m_prebuilt->skip_locked && arg == ULONG_MAX) | ||
| { | ||
| m_prebuilt->full_table_scan = true; |
There was a problem hiding this comment.
We are supposed to omit the space before any assignment operator.
…der a full-scan table lock MDEV-24813 introduced a switch innodb_table_lock_on_full_scan that requests a table lock on an innodb table for some unconditional SELECT/UPDATE/DELETE statements. With a full table lock, and when doing a covering scan, there is no need to request clustered index reads. This patch does so for X-locks in SELECT statements. Prior to this it is already the case for S-locks. There is one exception: we disable this optimization when inside a transaction with innodb_snapshot_isolation and a read view already open, in which case it needs trx_id obtained from the clustered index to check if there is a committed change the transaction never saw. Assisted-By: Claude Opus 5 <noreply@anthropic.com>
d75ffc7 to
8fe2322
Compare
…der a full-scan table lock
(TODO: improve commit message)
MDEV-24813 introduced a switch innodb_table_lock_on_full_scan that places a table lock on an innodb table for some unconditional SELECT statements.
With a full table lock, and when doing a covering scan, there is no need to acquire clustered locks. This patch does so for X-locks.
TODO: add code comments