Просто это выглядит очень подозрительно.., КХ на столько плохо сжимает данные, что они могут весить в два раза больше ?

кто-нибудь знает, как работает MV внутри при выборке из него? или тыкните, где почитать, плз
не допру, почему при чтении из view читается больше данных, глянул в логи, там есть дополнительный пункт в пайплайне (Filter), а если читать из .inner.view, то этого пункта нет и читается намного меньше данных
меньше/больше по кол-ву байт, а не по строкам

там довольно простой алгоритм сжатия, чем больше повторений и чем они длиннее, тем лучше сжатие

представь у тебя есть столбец состоящий из 1 и 0
теперь сравни такие случаи
Все лежит в 1 парте
1 лежат в одном парте, 0 лежат в другом
1 и 0 лежат в обоих партах

Не должно быть никакой разницы. Mv и .inner это одно и тоже. Может сломалось. Какая версия кх?

Нету такого механизма.

Спасибо! Попробую)

Такое есть в роадмапе на 2020 год, но сам понимаешь может и отложится

19.14.7.15
может быть из-за того, что я для альтера отцеплял вьюшку и прицеплял уже с новой схемой?

SELECT
  <columns>
    FROM <db>.distributed_table
            GLOBAL INNER JOIN (SELECT <colums> FROM <db>.distributed_table WHERE <clause> GROUP BY <column>) USING <columns>
    WHERE
            <clause>
    ORDER BY <column>

Видимо раньше или не проверялось либо было специально обойдено что global создает temporary table. Видимо надо bug завести

Не может

вот и я так думаю

но факт остается(

Завел вот тут: https://github.com/ClickHouse/ClickHouse/issues/11428
Спасибо за пояснение!

лог для .inner такой:
2020.06.04 13:30:52.672221 [ 66 ] {99461634-ad12-4c26-949e-3a8e37c13221} <Debug> db..inner.mt_log_view (SelectExecutor): Key condition: unknown, unknown, and
2020.06.04 13:30:52.672269 [ 66 ] {99461634-ad12-4c26-949e-3a8e37c13221} <Debug> db..inner.mt_log_view (SelectExecutor): MinMax index condition: (column 0 in [1588280400, +inf)), (column 0 in (-inf, 1588283999]), and
2020.06.04 13:30:52.672295 [ 66 ] {99461634-ad12-4c26-949e-3a8e37c13221} <Debug> db..inner.mt_log_view (SelectExecutor): Selected 1 parts by date, 1 parts by key, 3372 marks to read from 1 ranges
2020.06.04 13:30:52.678729 [ 66 ] {99461634-ad12-4c26-949e-3a8e37c13221} <Debug> executeQuery: Query pipeline:
Expression
Expression
 ParallelAggregating
  Expression × 8
   MergeTreeThread

2020.06.04 13:30:52.803225 [ 66 ] {99461634-ad12-4c26-949e-3a8e37c13221} <Information> executeQuery: Read 27618755 rows, 5.95 MiB in 0.134 sec., 206072548 rows/sec., 44.42 MiB/sec.

а для view такой:
2020.06.04 13:30:58.798955 [ 63 ] {7d5d0172-11c5-4529-a866-acb8ecded944} <Debug> db..inner.mt_log_view (SelectExecutor): Key condition: unknown, unknown, and
2020.06.04 13:30:58.799005 [ 63 ] {7d5d0172-11c5-4529-a866-acb8ecded944} <Debug> db..inner.mt_log_view (SelectExecutor): MinMax index condition: (column 0 in [1588280400, +inf)), (column 0 in (-inf, 1588283999]), and
2020.06.04 13:30:58.799027 [ 63 ] {7d5d0172-11c5-4529-a866-acb8ecded944} <Debug> db..inner.mt_log_view (SelectExecutor): Selected 1 parts by date, 1 parts by key, 3372 marks to read from 1 ranges
2020.06.04 13:30:58.800654 [ 63 ] {7d5d0172-11c5-4529-a866-acb8ecded944} <Debug> executeQuery: Query pipeline:
Expression
Expression
 ParallelAggregating
  Expression × 8
   Filter
    MergeTreeThread

2020.06.04 13:30:58.936572 [ 63 ] {7d5d0172-11c5-4529-a866-acb8ecded944} <Information> executeQuery: Read 27618755 rows, 540.71 MiB in 0.141 sec., 195196395 rows/sec., 3.73 GiB/sec.

видно для вьюшки лишний шаг Filter перед MergeTreeThread

Не может такого быть.  
Или удалились пользователи созданные через create user? там надо в 20.3 раскоментировать в config xml путь к стораджу юзеров инчае они только в памяти создаются и на диск не пишутся

пользователи все были на диске, обновил через apt-get, все исчезли

на продакшене сделал backup users.list и остальных файлов, накатил после обновления ошибка в PROFILE 'default'. руками поправил файлы, заработало

но таки все удалились с диска при простом обновлении 😬

Значит баг. Хотя в 20.3 они не были еще stable фичей. Попробую в 20.4 воспроизвести