Привет, есть следующие таблицы: ``` create table traffic ( did

UInt64,
....
report_date Date,
country_code LowCardinality(String)
)
engine = ReplicatedMergeTree('/clickhouse/tables/{shard}/reports_v0/traffic', '{replica}')
PARTITION BY toStartOfMonth(report_date)
ORDER BY (did, country_code)
SETTINGS index_granularity = 512;


create table competitors
(
did UInt64,
cid UInt64,
competition_level Float64,
country_code LowCardinality(String)
)
engine = ReplicatedMergeTree('/clickhouse/tables/{shard}/reports_v0/competitors', '{replica}')
ORDER BY (did, country_code)
SETTINGS index_granularity = 16384;
```
Запрос:
```
select distinct domain_name
from reports_v0.traffic t inner join (
select c.cid, max(c.competition_level) level from reports_v0.competitors c
prewhere c.did = cityHash64('google.com')
and c.cid != cityHash64('google.com')
group by c.cid
having level > 0
limit 100
) as s1 on t.did = s1.cid
order by s1.level desc;
```

Смотрю в логах и вижу, что сперва сканится левая таблица traffic.
Судя по документации сперва должна формироваться правая таблица, то есть подзапрос (тем более там всего 100 строк). Но в действительности все иначе почему?
join_algorithm = 'hash'

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

<Debug> reports_v0.traffic (7a3d90a4-abd9-4b40-ba3d-90a4abd99b40) (SelectExecutor): Key condition: unknown <Debug> reports_v0.traffic (7a3d90a4-abd9-4b40-ba3d-90a4abd99b40) (SelectExecutor): Selected 79/79 parts by partition key, 79 parts by primary key, 609223/609223 marks by primary key, 609223 marks to read from 79 ranges <Debug> reports_v0.traffic (7a3d90a4-abd9-4b40-ba3d-90a4abd99b40) (SelectExecutor): Reading approx. 311636945 rows with 4 streams (всего в таблице как раз таки 311636945 строк) .... <Information> executeQuery: Read 311702481 rows, 9.25 GiB in 2.699349693 sec., 115473175 rows/sec., 3.43 GiB/sec. Elapsed: 2.700 sec. Processed 311.70 million rows