да может
row policy добавляет фильтрацию в WHERE
эта фильтрация может добавлять дополнительное сканирование колонок которые высококардинальные и плохо размыты с точки зрения ORDER BY

Спасибо 🙏
1. а где можно почитать доку как храниться array?
2. если убрать indexOf (зафиксировать положение ключей/значений) будет ли лучше вариант с array?
select
 sum(tag_value[1]) as dirty_buffers
from
 pg.pg_sputnik_generic
where
 plugin = 'buffercache'
 and tag_value[2] = 1;

а не подскажете аналог with, хотелось бы к одному результату запроса дважды обратиться.
появилась необходимость к одной большой таблице присоединить другую большую таблицу, но джойн достаточно медленный, вариант хранить в словаре/движком джойн пока тоже актуален, но конечно забирает много памяти.
пока есть такой грустный вариант, неизвестно будет ли он быстрее обычного джойна(
select a.id, a.value, c.name from a
any left join (
select id, name from b where id in(select bid from a where ….)) as c
on a.bid=c.id
where ….

но запрос из табилчки a очень большой с накидыванием постоянно разных группировок и прочего.

с with получилось бы так:
with source as (select * from a where)
select s.id, s.value, c.name from source as s
any left join (select id, name from b where id in(select bid from source)) as c
on s.bid=c.id

мб есть варианты получше, нужен вариант промежуточного хранения результатов, можно попробовать создать доп таблицу/или еще что-то

проблема не в том как хранится array, в смысле доступа к элементам
Когда вы свалите 100 значений для разных key в array, все они попадут в один поток, пожмутся и лягут в один .bin файл, размером скажем 20ГБ.
Потом когда вам надо прочитать 64-е поле, придется читать все 20ГБ с диска.
Если положить не в один массив, а например в 10 массивов, придется прочитать например 2ГБ из поля myarray_bucket6

ну нету. with тоже не хранит никаких пром. результатов, это просто подстановки/макросы

обновился до 21.3.2.5-2, в целом проблема исчезла - спасибо!

до этого была  20.11.4

тоесть для доступа к одному значению array, распаковывается весь массив.

отсюда правило что в array не большое количество значений(скажем не больше 10).

тогда тормозить будет меньше?

да, все так.
Ну и никто не знает, что лучше для вас и ваших данных, может 10 таблиц, может EAV, может 800 полей в одной таблице, а может 60 полей и 20 полей массивов в которых упеханы но 10 атрибутов.

да, Алексей как раз на последнем митапе это говорил, про 21.3

Можете посоветовать что смотреть/почитать можно про оптимизацию запросов в clickhouse?

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

Связи с неопытностью не уверен что это корретный путь решения проблемы.

Есть два сервера КХ, один 19.17, другой 21.2
С первого на второй пытаюсь вызвать запрос через remote(), но запрос виснет и отваливается по тайм-ауту
Это может быть из-за несовместимости протоколов?

Теоретически да, версии сильно отличаются.

На сервере на который запрос отправляется есть какие то следы в логах?

DB::NetException. DB::NetException: Timeout exceeded while reading from socket (10.234.29.51:9000): while receiving packet from xx.xx.xx.xx:9000.
Query was cancelled.

Это который отправляет похоже?

remote(... system.one) тоже?

Да, который отправляет. Запустил сейчас еще раз. Пока думает, но при запросе сразу выдал в логе варнинг про настройку:[
<Warning> Settings: Unknown setting allow_experimental_data_skipping_indices, skipping

тоже

на remote сервере
запрос в логи приходит?

tcpdump надо еще посмотреть