Details
-
New Feature
-
Status: In Progress (View Workflow)
-
Critical
-
Resolution: Unresolved
Description
extend MDEV-11084 to also not open automatically excluded partitions
In particular, INSERT, DELETE, UPDATE and SELECT should not open any partitions that can be excluded by parsing the WHERE clause.
Details about what is [not] opened/locked
The steps at query processing are:
1. open_tables() call
This will create handler object and call handler::open.
Note that this is done only if the table was not found in the Table Cache. Most queries are expected to hit the table cache and will not do this.
Example stack traces:
#1 0x000055555670182b in innobase_create_handler
|
#2 0x00005555563167db in get_new_handler
|
#3 0x00005555566092a6 in ha_partition::create_handlers
|
#4 0x000055555660a013 in ha_partition::setup_engine_array
|
#5 0x000055555660a573 in ha_partition::get_from_handler_file
|
#6 0x0000555556601fc2 in ha_partition::initialize_partition
|
#7 0x0000555556601411 in partition_create_handler
|
#8 0x00005555563167db in get_new_handler
|
#9 0x00005555560b5d9d in TABLE_SHARE::init_from_binary_frm_image
|
#10 0x00005555560b128f in open_table_def
|
#11 0x0000555556236d6a in tdc_acquire_share
|
#12 0x0000555555e85f2e in open_table
|
#0 ha_innobase::open
|
#1 0x000055555631eb35 in handler::ha_open
|
#2 0x000055555661a5e4 in ha_partition::open_read_partitions
|
#3 0x000055555660bed2 in ha_partition::open
|
#4 0x000055555631eb35 in handler::ha_open
|
#5 0x00005555560bde90 in open_table_from_share
|
#6 0x0000555555e8656e in open_table
|
2. lock_tables (actually statement start)
Historically this was "locking" for MyISAM. Now it's more about informing the storage engine that the statement is about to start. The calls made are handler::store_lock and handler::external_lock. Inside a transaction or statement, handler::start_stmt is called instead.
Example stack traces:
#0 ha_innobase::store_lock
|
#1 0x000055555660d248 in ha_partition::store_lock
|
#2 0x00005555564968e4 in get_lock_data
|
#3 0x00005555564950a0 in mysql_lock_tables
|
#4 0x0000555555e8e5d8 in lock_tables
|
#0 ha_innobase::external_lock
|
#1 0x000055555632b7f0 in handler::ha_external_lock
|
#2 0x000055555660cd13 in ha_partition::external_lock
|
#3 0x000055555632b7f0 in handler::ha_external_lock
|
#4 0x0000555556495592 in lock_external
|
#5 0x0000555556495218 in mysql_lock_tables
|
#6 0x00005555564950d4 in mysql_lock_tables
|
#7 0x0000555555e8e5d8 in lock_tables
|
3. Statement end: close_thread_tables
This will make handler::reset call
#0 ha_innobase::reset
|
#1 0x000055555632bcb9 in handler::ha_reset
|
#2 0x000055555661af11 in ha_partition::reset
|
#3 0x000055555632bcb9 in handler::ha_reset
|
#4 0x0000555555e83f6e in close_thread_table
|
#5 0x0000555555e83bf3 in close_thread_tables
|
What this MDEV does
It is about not doing the Step#2. lock_tables (actually statement start) for partitions that the statement will not access.
TODO: and also Step 3?
Attachments
Issue Links
- blocks
-
MDEV-17613 MIN/MAX Optimization (Select tables optimized away) does not work
- Stalled
- causes
-
MDEV-34780 MDEV-20250: bb-11.6-mdev20250-hf preliminary test results: various failures
- Confirmed
- relates to
-
MDEV-28883 Re-design the upper level of handling UPDATE and DELETE statements
- Closed
-
MDEV-11084 Select statement with partition selection against MyISAM table opens all partitions
- Closed
-
MDEV-19002 Partition performance optimization
- Stalled
-
MDEV-20376 Assertion in ha_maria::close() upon complex SELECT from specific data
- Closed