Limitations

Overriding config options should in many cases be possible as long as there is a mitigation strategy to ensure that a change in options does not cause the database state of a table to become inconsistent. But what does this strategy look like? And if we allow a config option to be overridden on a live table (one that a user has access to), how should we apply these new options to shared data like merging runs? Moreover, would we answer these questions differently for each type of config option?

For now, it seems to be the most straightforward to limit the config options we allow to be overridden, and that we only change the config options offline. That is, we override the config option just before opening a snapshot from disk. At that point, there is no sharing because the table is not live yet, which simplifies how changing a config option is handled.

Another complicating factor is that we have thought about the possibility of restoring sharing of ongoing merges between live tables and newly opened snapshots. At that point, we run into the same challenges again... But for now, changing only the disk cache policy and merge batch size offline should work fine.