**Describe the bug**

Since we upgraded to 20.10.3.30, one of our clickhouse cluster takes much more time to start. (Up to 50 minutes, and before it took ~3 minutes)
The log file is filled with
>  <Debug> DiskLocal: Reserving 1.00 MiB on disk `default`, having unreserved 16.90 TiB

Additionally, the memory consumption increases, linearly, a lot (up to arround 230 G for us) and then drop back to normal values once clickhouse finished starting up. During that loading phase, a single CPU core is used at 100%.
If that memory is not available for the machine, clickhouse gets OOMed by the kernel.


**How to reproduce**
* Issue appeared after we upgraded to ClickHouse server version 20.10.3.30

* How could I find wich of our tables may be responsible for that ?


**Expected behavior**
A fast startup :)

{
            if (isDateTime(minmax_idx_columns_types[i])
                || isDateTime64(minmax_idx_columns_types[i])
            )
            {
                if (!has_datetime_column)
                {
                    minmax_idx_time_column_pos = i;
                    has_datetime_column = true;
                }
                else
                {
                    
                    minmax_idx_time_column_pos = -1;
                }
            }
        }
    }
}
void MergeTreeData::checkTTLExpressions(const StorageInMemoryMetadata & new_metadata, const StorageInMemoryMetadata & old_metadata) const
{
    auto new_column_ttls = new_metadata.column_ttls_by_name;
    if (!new_column_ttls.empty())
    {
        NameSet columns_ttl_forbidden;
        if (old_metadata.hasPartitionKey())
            for (const auto & col : old_metadata.getColumnsRequiredForPartitionKey())
                columns_ttl_forbidden.insert(col);
        if (old_metadata.hasSortingKey())
            for (const auto & col : old_metadata.getColumnsRequiredForSortingKey())