**Describe the bug**

I have a table like:

```
CREATE TABLE test (
    time DateTime64(3)
    ...
) ENGINE = MergeTree()
PARTITION BY toStartOfInterval(time, INTERVAL 1 HOUR)
...
```

But when I search in `system.parts` it does not appear to have the `min/max` columns appropriately set?

```
partition:                             2020-06-01 01:00:00
min_date:                              1970-01-01
max_date:                              1970-01-01
min_time:                              1970-01-01 00:00:00
max_time:                              1970-01-01 00:00:00
```

I assume that if these were correctly set, doing a `select toStartOfInterval(time, interval 1 day), count()` type query would be pretty instant rather than trying to scan everything? I am guessing this is due to the `DateTime64` type in use?

Clickhouse 20.11.3.3

if (it_part == data_parts_by_info.end())
        throw Exception("No such data part " + part_to_detach->getNameWithState(), ErrorCodes::NO_SUCH_DATA_PART);
    
    DataPartPtr part = *it_part;
    if (part->getState() == DataPartState::Committed)
    {
        removePartContributionToDataVolume(part);
        removePartContributionToColumnSizes(part);
    }
    modifyPartState(it_part, DataPartState::Deleting);
    part->renameToDetached(prefix);
    data_parts_indexes.erase(it_part);
    if (restore_covered && part->info.level == 0)
    {
        LOG_WARNING(log, "Will not recover parts covered by zero-level part {}", part->name);
        return;
    }
    if (restore_covered)
    {
        Strings restored;
        bool error = false;
        String error_parts;
        Int64 pos = part->info.min_block;
        auto is_appropriate_state = [] (DataPartState state)
        {
            return state == DataPartState::Committed || state == DataPartState::Outdated;
        };
        auto update_error = [&] (DataPartIteratorByInfo it)
        {
            error = true;