**Describe the situation**
What exactly works slower than expected?
Seems that LIVE VIEWS are underusing the available CPU.
 
**How to reproduce**
I'm using a GCP vm with 4 cpus, 32 GB ram and 727 GB disk.
Next code creates a table called 'test' and inserts random values into it. 
It will insert 1 billion rows as transactions between 21-09-01 and 21-09-10, with random values in amount column.
Then you have the selects to compare the performace of a live view that groups the amount transactioned each day, with the performance of a 'pure select' (same as the LIVE VIEW definition).
If you make an htop during the simple select you could see all cores working together, but at the first execution of select to the LIVE VIEW you will see cores with no use and a decrease on the performace of the query compared to the orginal select.
If you use more data or more complex querys with agg columns it turns worse.
 
```
-- create table test
CREATE TABLE test (
    id Int64,
    timestamp DateTime,
    amount Decimal(4,2)
) ENGINE = MergeTree()
ORDER BY timestamp AS
SELECT 
    *,
    toDateTime((modulo(rand(),10)/10)*(toUnixTimestamp('2021-09-10 00:00:00')-toUnixTimestamp('2021-09-01 00:00:00'))+toUnixTimestamp('2021-09-01 00:00:00')),
    toDecimal32(((modulo(rand(),100)/100)*(2)+(-1))*1000,2) as amount
FROM numbers(0, 1000000000)

-- just select and see htop
SELECT
    toStartOfDay(timestamp),
    MAX(amount) AS amount
FROM test AS mc
GROUP BY
    toStartOfDay(timestamp)
ORDER BY toStartOfDay(timestamp) DESC

-- create live view
CREATE LIVE VIEW test_lv WITH REFRESH 120
AS SELECT
    toStartOfDay(timestamp) as timestamp,
    MAX(amount) AS amount
FROM test AS mc
GROUP BY
    timestamp
ORDER BY timestamp DESC;

-- select and execute for the first time the live view (see htop)
SELECT * FROM test_lv ORDER BY timestamp DESC LIMIT 10;
```

**Which ClickHouse server version to use**
version 21.9.4 revision 54449

**Which interface to use, if matters**
clickhouse-client version 21.9.4.35 (official build)

**Expected performance**
I was expecting that live view executes over all the hardware available, with a performance comparable with the 'pure select' ones.

**Additional context**
I'm attaching some screenshots where you can check performance issue cleary

pure select performance
![select-time](https://user-images.githubusercontent.com/92802518/139358759-adcc32fa-5e94-40a9-93ff-6520780c5140.png)

pure select cores
![select-cores](https://user-images.githubusercontent.com/92802518/139358772-2c30e022-3b1e-4155-bc3b-a54bd1a5442c.png)

live view performance
![live-view-time](https://user-images.githubusercontent.com/92802518/139358831-cdeb8bca-9749-408c-895e-1d3f2fff3d73.png)

live view cores
![live-view-cores](https://user-images.githubusercontent.com/92802518/139358851-9e3c4832-0674-4394-92be-2a480cb3aa7f.png)



builder.addSimpleTransform([&](const Block & cur_header)
    {
        return std::make_shared<SquashingChunksTransform>(
            cur_header,
            getContext()->getSettingsRef().min_insert_block_size_rows,
            getContext()->getSettingsRef().min_insert_block_size_bytes);
    });
    return builder;
}
void StorageLiveView::writeIntoLiveView(
    StorageLiveView & live_view,
    const Block & block,
    ContextPtr local_context)
{
    auto output = std::make_shared<LiveViewSink>(live_view);
    
    
    
    {
        std::lock_guard lock(live_view.mutex);
        if (!live_view.hasActiveUsers())
        {
            live_view.reset();
            return;
        }
    }
    bool is_block_processed = false;