Comments - Adding columns to a table with full text column extremely slow
Content reproduced on this site is the property of its respective owners,
and this content is not reviewed in advance by MariaDB. The views, information and opinions
expressed by this content do not necessarily represent those of MariaDB or any other party.
Hello -
This is using InnoDB.
Here is part of the output from my script,without any full-text columns - the numbers in brackets like [0.007926] is the timing in seconds.
There are many limitations around
FULLTEXT INDEX
in InnoDB: https://mariadb.com/resources/blog/initial-impressions-of-innodb-fulltext/MDEV-17459 prevents the
ADD COLUMN
from being instantaneous. To add insult to the injury, if anALTER TABLE
operation would involve creating multipleFULLTEXT INDEX
(like it would if the table were to be rebuilt for adding the columns), then InnoDB would refuse a native operation, and the inefficientALGORITHM=COPY
would be used.You could try dropping all fulltext indexes first, and then perform
ALTER TABLE t FORCE, ADD COLUMN …, ADD FULLTEXT INDEX …, ALGORITHM=INPLACE
(creating at most one fulltext index). TheFORCE
keyword preventsALGORITHM=INSTANT
operation and forces a rebuild. It should not be necessary, but I did not test it.If there are multiple fulltext indexes, you can create them one at a time with subsequent
ALTER TABLE t ADD FULLTEXT INDEX
statements. Note: when you add the first fulltext index, a hiddenFTS_DOC_ID
column will be created inside InnoDB. So, typically adding the first fulltext index will require the table to be rebuilt. Also, note that when anyFULLTEXT
orSPATIAL
index are to exist after theALTER TABLE
, the operation cannot be executed online (while allowing concurrent writes to the table).Ok I understand what you are saying, i think... but these tables are completely empty (has zero rows). So, even if the table has to be completely re-built... it's an empty table. Why is it taking so long?