**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.
* It will also store needed stuff for projection query pipeline.
      *
      * QueryProcessingStage::Enum required for Distributed over Distributed,
      * since it cannot return Complete for intermediate queries never.
      */
    virtual QueryProcessingStage::Enum
    getQueryProcessingStage(ContextPtr, QueryProcessingStage::Enum, const StorageMetadataPtr &, SelectQueryInfo &) const
    {
        return QueryProcessingStage::FetchColumns;
    }
    /** Watch live changes to 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` info is also written to what stage the request was processed.
     * (Normally, the function only reads the columns from the list, but in other cases,
     *  for example, the request can be partially processed on a remote server.)
     *
     * 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.
     *
     * It is guaranteed that the structure of the table will not change over the lifetime of the returned streams (that is, there will not be ALTER, RENAME and DROP).
     */
    virtual Pipe watch(