Secondary index update lag during concurrent schema change in Phoenix

When a secondary index is defined on a Phoenix table, writes are normally reflected in the index after a short background update.

Under a workload of concurrent inserts while an ALTER TABLE ADD COLUMN statement is executing, the index update lag can increase, and the index may temporarily miss some newly added column values.

The goal is to understand the expected lag duration and consistency guarantees given the configuration of phoenix.index.update.thread.count, the HBase region server flush interval, and the phoenix.index.update.sync flag in Phoenix 5.x with HBase 2.x.

What is the typical index update latency observed during the schema change? How does varying the thread pool size affect the lag and the risk of stale index reads? Does disabling synchronous updates guarantee bounded staleness, or can it lead to unbounded inconsistency?