**How to reproduce**
Clickhouse server 20.13.1.5273
```
CREATE TABLE default.test
(
`key` UInt32,
`ts` DateTime CODEC(DoubleDelta, LZ4),
`db_time` DateTime DEFAULT now() COMMENT 'spout-ignore' CODEC(DoubleDelta, LZ4)
)
ENGINE = MergeTree
PARTITION BY toStartOfTenMinutes(db_time)
ORDER BY (key, ts)
TTL db_time + toIntervalHour(3)
SETTINGS index_granularity = 8192, merge_with_ttl_timeout = 3600, min_rows_for_compact_part = 1000000, min_bytes_for_compact_part = 200000000, in_memory_parts_enable_wal = 0;


INSERT INTO test(key, ts) SELECT number % 1000, now() + intDiv(number,1000) FROM numbers(500);

SELECT * FROM test;
500 rows in set. Elapsed: 0.003 sec.

DETACH TABLE test;

ATTACH TABLE test;

SELECT * FROM test;

0 rows in set. Elapsed: 0.002 sec.
```

**Expected behavior**
Clickhouse would flush parts on disk.
/** Read a set of columns from the table.
      * Accepts a list of columns to read, as well as a description of the query,
      *  from which information can be extracted about how to retrieve data
      *  (indexes, locks, etc.)
      * Returns a stream with which you can read data sequentially
      *  or multiple streams for parallel data reading.
      * The `processed_stage` must be the result of getQueryProcessingStage() function.
      *
      * context contains settings for one query.
      * Usually Storage does not care about these settings, since they are used in the interpreter.
      * But, for example, for distributed query processing, the settings are passed to the remote server.
      *
      * num_streams - a recommendation, how many streams to return,
      *  if the storage can return a different number of streams.
      *
      * metadata_snapshot is consistent snapshot of table metadata, it should be
      * passed in all parts of the returned pipeline. Storage metadata can be
      * changed during lifetime of the returned pipeline, but the snapshot is
      * guaranteed to be immutable.