**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 :)

{
    std::optional<std::unordered_set<String>> partition_ids;
    if (partitions)
        partition_ids = getPartitionIDsFromQuery(*partitions, restorer.getContext());
    auto backup = restorer.getBackup();
    Strings part_names = backup->listFiles(data_path_in_backup);
    boost::remove_erase(part_names, "mutations");
    auto restored_parts_holder
        = std::make_shared<RestoredPartsHolder>(std::static_pointer_cast<MergeTreeData>(shared_from_this()), backup, part_names.size());
    fs::path data_path_in_backup_fs = data_path_in_backup;
    size_t num_parts = 0;
    for (const String & part_name : part_names)
    {
        const auto part_info = MergeTreePartInfo::tryParsePartName(part_name, format_version);
        if (!part_info)
        {
            throw Exception(ErrorCodes::CANNOT_RESTORE_TABLE, "File name {} is not a part's name",
                            String{data_path_in_backup_fs / part_name});
        }
        if (partition_ids && !partition_ids->contains(part_info->partition_id))