19 тыс. сотрудников на общую суммы 5,9 млрд рублей

Получается, что в Яндексе средний оклад - 310 тыс. рублей. Это сильно не сходится со статистикой хабра:

В Интернете есть много мест, где эти вопросы можно обобсудить

Приведите, пожалуйста, несколько примеров

WHERE g.node1 = sg.node2
AND not (g.node1 = ANY(sg.path)) -- тоже самое, но останавливаемся на первом вхождении
AND ((sg.depth = 1) 
     or (sg.depth > 2 and sg.node1 > g.node1)
    ) -- исключаем логические повторы
      -- актуально если 30 2 3 1003 и 30 3 2 1003 - одно и тоже
      -- оставляем только одну последовательность (30 2 3 1003)

public> select count(*) from (select clientid from tbl_fact
            where dt between '2021-01-01' and '2021-12-01' group by clientid) q
[2022-01-20 14:57:33] 1 row retrieved starting from 1 in 3 s 322 ms (execution: 3 s 302 ms, fetching: 20 ms)

create index tbl_fact_idx2 on tbl_fact(clientid, dt);
explain analyze
select count(*) from (select clientid from tbl_fact
where dt between '2021-01-01' and '2021-12-01' group by clientid) q;

Aggregate  (cost=641207.12..641207.13 rows=1 width=8) (actual time=5522.464..5522.466 rows=1 loops=1)
  ->  Group  (cost=0.44..594183.54 rows=3761887 width=4) (actual time=55.265..5263.736 rows=4817602 loops=1)
        Group Key: tbl_fact.clientid
        ->  Index Only Scan using tbl_fact_idx2 on tbl_fact  (cost=0.44..552706.71 rows=16590731 width=4) (actual time=0.095..3838.740 rows=16545711 loops=1)
              Index Cond: ((dt >= '2021-01-01'::date) AND (dt <= '2021-12-01'::date))
              Heap Fetches: 0

...
CREATE INDEX tbl_fact_idx ON tbl_fact (clientid);
vacuum analyze  tbl_fact;

-- 10 s 72 ms
public> select count(distinct clientid) from tbl_fact
[2022-01-20 00:32:34] 1 row retrieved starting from 1 in 10 s 72 ms (execution: 10 s 31 ms, fetching: 41 ms)


--3 s 712 ms
public> select count(*) from (select clientid from tbl_fact group by clientid) q
[2022-01-20 00:33:45] 1 row retrieved starting from 1 in 3 s 712 ms (execution: 3 s 672 ms, fetching: 40 ms)

• Добавить кэш от еще нескольких агрегаторов (сейчас только один). Этот вариант понятно как реализовывать, но он все равно не решит проблему до конца, всегда будут оставаться «белые пятна»;
• Предсказывать цены на билеты, если они сейчас отсутствуют в кэше для их использования в комбинаторе (для того, чтобы забить всю сетку origin/destination/date). Здесь у меня больше вопросов, чем ответов, но интуитивно кажется, что это единственный вариант.