Background compaction only starts when different conditions are met. One of them is related to the amount of space that can be theoretically reclaimed by the end of the operation and the free_space_target set by the application (default is currently 20MB).

If the application sets a free_space_target of X bytes and there are more than X bytes that can be recovered, compaction will try to recover as much as possible until there is no more work. This design should be discussed as:

• The free_space_target could be seen as the amount of space to reclaim before stopping.
• Spending too much time on a table could affect performance especially if this is a hot table.
• If parallel work is being done on the table being compacted, compaction may keep finding work to do and keep compacting the table, even if it is not much. In that case, the potential disruption might not be worth it.
  • WT-12297 could be used for that specific work.

The goal of the ticket is to clarify what should be done in those scenarios.