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
MDEV-33087 ALTER TABLE...ALGORITHM=COPY should build indexes more efficiently #3145
base: 10.11
Are you sure you want to change the base?
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks mostly OK. I think that we must keep using the old code path if FOREIGN KEY
constraints need to be enforced.
f0ea2cf
to
fdf922b
Compare
fdf922b
to
68ac097
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are some initial comments. I think that MDEV-33809 needs to be fixed before this can be merged.
storage/innobase/row/row0ins.cc
Outdated
/* MDEV-25036 FIXME: check also foreign key | ||
constraints */ | ||
ut_ad(!trx->check_foreigns); | ||
ut_ad(index->table->skip_alter_undo | ||
|| !trx->check_foreigns); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to have a comment that explains where the FOREIGN KEY
constraints will be enforced during ALTER TABLE…ALGORITHM=COPY
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that a source code comment here about the FOREIGN KEY
constraint enforcement would be useful. In which function is that check executed?
f5dabc8
to
c4b52b0
Compare
0baa8f6
to
a6bb0ca
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, I think that we are almost there.
a6bb0ca
to
af9d45b
Compare
storage/innobase/row/row0ins.cc
Outdated
/* MDEV-25036 FIXME: check also foreign key | ||
constraints */ | ||
ut_ad(!trx->check_foreigns); | ||
ut_ad(index->table->skip_alter_undo | ||
|| !trx->check_foreigns); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that a source code comment here about the FOREIGN KEY
constraint enforcement would be useful. In which function is that check executed?
cbaffd3
to
06ef346
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, the code changes look fine to me, but I think that we need to add some test coverage.
dd1e145
to
1f66c6c
Compare
mysql-test/suite/innodb/r/bulk_copy_alter,non_bulk_alter_copy.rdiff
Outdated
Show resolved
Hide resolved
…iciently - During copy algorithm, InnoDB should use bulk insert operation for row by row insert operation. By doing this, copy algorithm can effectively build indexes. This optimization is disabled for temporary table, versioning table and table which has foreign key relation. Introduced the variable innodb_alter_copy_bulk to allow the bulk insert operation for copy alter operation inside InnoDB. This is enabled by default ha_innobase::extra(): HA_EXTRA_END_ALTER_COPY mode tries to apply the buffered bulk insert operation, updates the non-persistent table stats. row_merge_bulk_t::write_to_index(): Update stat_n_rows after applying the bulk insert operation row_ins_clust_index_entry_low(): In case of copy algorithm, switch to bulk insert operation. copy_data_error_ignore(): Handles the error while copying the data from source to target file.
1f66c6c
to
55fb366
Compare
Description
How can this PR be tested?
Tested with large data set:
Existing alter copy algorithm:
MariaDB [test]> alter table t1 force, algorithm=copy;
Query OK, 6291456 rows affected (12 min 18.519 sec)
Records: 6291456 Duplicates: 0 Warnings: 0
With bulk insert (copy algorithm)
MariaDB [test]> alter table t1 force, algorithm=copy;
Query OK, 6291456 rows affected (7 min 30.760 sec)
Records: 6291456 Duplicates: 0 Warnings: 0
create..select copy algorithm:
MariaDB [test]> create table t2 select * from t1;
Query OK, 6619136 rows affected (7 min 5.126 sec)
Records: 6619136 Duplicates: 0 Warnings: 0
create..select (with bulk insert):
MariaDB [test]> create table t2 select * from t1;
Query OK, 6619136 rows affected (4 min 54.647 sec)
Records: 6619136 Duplicates: 0 Warnings: 0
Basing the PR against the correct MariaDB version
PR quality check