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

PartLogElement::Type type,
    const ExecutionStatus & execution_status,
    UInt64 elapsed_ns,
    const String & new_part_name,
    const DataPartPtr & result_part,
    const DataPartsVector & source_parts,
    const MergeListEntry * merge_entry)
try
{
    auto table_id = getStorageID();
    auto part_log = getContext()->getPartLog(table_id.database_name);
    if (!part_log)
        return;
    PartLogElement part_log_elem;
    part_log_elem.event_type = type;
    if (part_log_elem.event_type == PartLogElement::MERGE_PARTS)
    {
        if (merge_entry)
        {
            part_log_elem.merge_reason = PartLogElement::getMergeReasonType((*merge_entry)->merge_type);
            part_log_elem.merge_algorithm = PartLogElement::getMergeAlgorithm((*merge_entry)->merge_algorithm);
        }
    }
    part_log_elem.error = static_cast<UInt16>(execution_status.code);
    part_log_elem.exception = execution_status.message;