This is working as (currently) designed.

Instant VARCHAR extension is supported already in MariaDB Server 10.2, but starting with 10.4 we support it in a few more cases. That operation does not modify the table data at all; it is a strict metadata-only change.

The counter Innodb_instant_alter_column was introduced in MDEV-11369 (Instant ADD COLUMN, MariaDB Server 10.3.2) and its use was extended in MDEV-15562 (Instant DROP COLUMN or permutation of columns, MariaDB Server 10.4.0). The idea is to count those ALTER TABLE statements that would result in the table being in a backward-incompatible format. Prior to those changes, adding or dropping columns always required that the table be rebuilt. The instant ALTER for those operations involves more than updating the metadata in the data dictionary: we will modify the table data by inserting or updating a hidden metadata record, which is making the data file incompatible with earlier versions.

I think that it makes sense to have a counter for monitoring the ALTER TABLE operations that avoid a table rebuild by changing the data file format. I agree that the name of the counter could be less misleading.

elenst, how would you propose to rectify the situation? If we introduce another counter for instant ALTER TABLE operations, I think that that one would have to be incremented for all trivial changes, such as renaming columns or changing the DEFAULT value of a column. InnoDB cares about column names (because it is updating them in its own persistent data dictionary), but it does not care at all about changes of DEFAULT values.

I think that if a status variable with the name Innodb_instant_alter_column exists and is shown to users, it should count either all ALTER TABLE operations on InnoDB tables anyhow modifying columns with instant algorithm applied implicitly or explicitly (interpretation of the name: <InnoDB> - <instant_alter> -< column>), or, much more narrowly, all ALTER TABLE ... ALTER COLUMN operations on InnoDB tables with instant algorithm applied implicitly or explicitly (interpretation of the name: <InnoDB> - <instant> - <alter_column>).

Whether there is a need of such variable shown to users is another question. I don't have a strong opinion on the subject, but I lean towards "no", because I can't think of any reason why a user would want to count only instant modifications of a column, but not, for example, index operations, or only instant operations which InnoDB "cares about" and not the other ones. That said, I don't really know why a user would need an instant counter at all. Such status variables are very useful for testing, but I am not so sure about users. So, I wouldn't argue if it was deprecated/removed or made debug.

I also don't have a strong opinion about a counter "for monitoring the ALTER TABLE operations that avoid a table rebuild by changing the data file format". If it serves any purpose for users – and I don't know what that purpose would be – then it surely should be called accordingly, and count whatever needs to be counted for the said purpose. If it only makes sense for debugging/testing, then maybe it should be a debug-only counter.

I don’t know if it serves a purpose for users, but I would like to be able to run innodb.instant_alter and other instant ALTER TABLE tests on non-instrumented (release) executables while being able to assert that the correct number of operations is being executed. If I remember correctly, you requested for such a counter during MDEV-11369 testing.

If you would like to extend this operation to cover all instant column changes (such as renaming, changing default value, changing column comment, extending a VARCHAR, removing a NOT NULL attribute from a ROW_FORMAT=REDUNDANT) table, that could be thinkable.

But I guess we should not increment the thus named counter for any arbitrary ALTER TABLE…ALGORITHM=INSTANT operations, such as changing an index comment.

Correct, I requested it for testing purposes. I said back then as well that I would be fine with it being debug and/or temporary. Also, to my knowledge, at that point INSTANT algorithm only applied to column addition.

I don't mind it to stay in the release builds either, but then it should mean what a user would reasonably expect it to mean. I (as a user) would expect it to count all column modifications performed using instant algorithm on InnoDB tables, although there might be other opinions.

And certainly, a counter named Innodb_instant_alter_column should count only column modifications, not any other ALTERs. My point about indexes was that if users need any counter at all, it is probably a counter for any instant operations, not only for columns. But it would have to be named differently of course.