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

почему не startsWith или LIKE 'path%' (вроде тоже подойдет?) мы же всегда можем узнать родителя и тд?

нам приходит не середина пути, а целиком от родителя?

multiSearch* позволяет получить весь массив и обойтись без joinа к фильтру

with (
  select groupArray(objfilter) from (
    select 'lvl1=2,lvl2=3,lvl3=5' as objfilter UNION ALL
    select 'lvl1=1,lvl2=3,lvl3=5,lvl4=43' as objfilter 
  )
) as fltArr
select fltArr, * from
(
select 'lvl1=2,lvl2=3,lvl3=5' as objpath UNION ALL
select 'lvl1=2,lvl2=3,lvl3=5,lvl4=2' as objpath UNION ALL
select 'lvl1=2,lvl2=3,lvl3=5,lvl4=44' as objpath UNION ALL
select 'lvl1=3,lvl2=3,lvl3=6' as objpath UNION ALL
select 'lvl1=2,lvl2=3' as objpath UNION ALL
select 'lvl1=1,lvl2=3,lvl3=5' as objpath  
) t
WHERE multiSearchFirstIndex(objpath, fltArr)>0;

это вернет всех детей на все фильтры без join-ов

а, поня
найти всех, с кем совпало

хотя оно с индексом не дружит...

ну в идеале нам нужно найти все веточки, которые нам интересны.
сделать на 1 шаг назад и отфильтровать все остальное в WHERE с помощью индекса

не очень понял "на 1 шаг назад", это как?

что бы получить какие то данные еще и для родителя?

с родителями как я понял лучше вообще отдельно разбираться потому что с ними просто (можно фильтр препроцесснуть и вытащить всех родителей с помощью URLPathHierarchy или dictGetHierarchy, или в аппе)

если честно, мы не пробовали вот так ещё =)
startsWith() or startsWith() or startsWith or ....повторять до упаду...
- насколько оно будет умирать если таких условий будет оооочень много

но варианты с CROSS JOIN или arrayExists дружно падают по памяти, когда элементов внутри фильтра становится много
100 - 2ГБ
200 - 4 ГБ
300 - 9 ГБ
500 - 20 ГБ

ну и в этом тренде

как вы думаете, а на это можно запилить импрувмент?
при использовании WITH результат подзапроса рид онли сам по себе... почему он падает с аллокацией?

```
3. MemoryTracker::alloc(long) @ 0x8f3fec3 in /usr/bin/clickhouse
4. ? @ 0xd5a618d in /usr/bin/clickhouse
5. DB::ColumnArray::replicateString(DB::PODArray<unsigned long, 4096ul, Allocator<false, false>, 15ul, 16ul> const&) const @ 0xd5a9751 in /usr/bin/clickhouse
6. ? @ 0xd5a9b60 in /usr/bin/clickhouse
7. DB::ColumnArray::replicateTuple(DB::PODArray<unsigned long, 4096ul, Allocator<false, false>, 15ul, 16ul> const&) const @ 0xd5a9d1d in /usr/bin/clickhouse
8. DB::ColumnArray::replicate(DB::PODArray<unsigned long, 4096ul, Allocator<false, false>, 15ul, 16ul> const&) const @ 0xd5aa5f3 in /usr/bin/clickhouse
9. DB::ColumnConst::convertToFullColumn() const @ 0xd5b2b2d in /usr/bin/clickhouse
10. DB::FunctionArrayMapped<DB::ArrayFirstImpl, DB::NameArrayFirst>::executeImpl(DB::Block&, std::__1::vector<unsigned long, std::__1::allocator<unsigned long> > const&, unsigned long, unsigned long) @ 0xb3e5650 in /usr/bin/clickhouse

```

Ну, если все 100к условий писать то больно.

Но другой вопрос, что если мы будет разбивать эти условия и группировать по префиксу начальному

я думаю это вообще как бы баг по идее...
вот у меня есть WITH, почему от результата его размера так сильно зависит отъедание памяти запросом? эт ж константные данные в рамках выполнения запроса

собственно из-за всех этих оптимизаций в КХ нету CTE и прочих радостей... сейчас попробую сделать generic-запрос на разные объемы

WITH range(1, number) as val SELECT val FROM numbers(10);
ну не совсем, кмк

сейчас попробуем

нет, нужно WITH (SELECT ...)