строк или столбцов?:)

без джойнов,  на денормализованных данных,
кх  и пг они про разное

КХ не может обработать малое кол-во строк без дичайшего оверхеда

постресс и больше 10К сделает, но если к диску не нужно каждый раз ходить. чуть сорвались в какой-нибудь range scan  и все. это вот если все чтения по 1 блоку по 8к и не больше и если они выполняются последовательно, то 10К - это потолок

ну это да, но он и не про мало строк. он же big data, за что и любим

Да, с этим не спорю. У нас идет речь о том, чтобы делать не очень сложные выборки, но много

и в оракле также. невозможно в 1 сессию ( последовательные запросы) сделать 100К и при это таких, что каждый раз нужно читать с диска.

КХ сразу выделяет половину ядер и кучу памяти на запрос и нету кеша планов, и распаршенных запросов.

Вот не верю что PG сможет распарсить 10к SQL в сек

у КХ даже нет кэша запросов. он вам всегда парсит заново.

а зачем? если надо парсить 10к запросов даже в день,  то что то не так

ну в rdbms

Зачем ему постоянно парсить? У него же есть prepared statements

Посоветуйте, пожалуйста, про словари. Есть база постгеса с таблицей, из которой табличку под словарь нужно делать запросом. Сейчас мы на основании запроса делаем вью тоже в постгесе, и обновляем, скажем, раз в сутки. И на этот вью настраиваем словарь по odbc, он тоже с какой-то периодичностью обновляется. Я правильно понимаю, что нет возможности пропустить этот шаг с вью? нельзя же в описании словаря использовать запрос? а если я сделаю вью в кликхаусе (к таблице по odbc)  это будет лучше? или при недоступности источника все сломается?

да, я и не спорю,что он нужен

у КХ-а то нет например

💓

В общем, как я понял, кликхаус это не про хайлоад

вы запустите perf и посмотрите, куда у вас время уходит, когда вы делаете select 1. Нам расскажите

это OLAP, а не OLTP. вам никакой OLAP не даст такого. поправте кто если знает такой OLAP