дядя вы чего? В jdbc драйвере CH реализована JDBC спецификация. Там написано Columns are numbered from 1.

да я все понимаю, но лично я у себя в драйверах своих это бы исправил, ибо не верно это вот и все.

это примерно как если бы двигатели внутреннего сгорания на бмв не изменялись с 1800 годов

ээээ так все JDBC приложения сразу сломаются, они же ожидают что с 1 начинается, они же вообще не в курсе что они с КХ работают через драйвер КХ.

нене это у вас в прикуривателе 5 вольт, и педали тормоза и газа местами поменяны.

опять не понятно, я качаю драйвер у яндекса, он внутри там у себя тянет jdbc ок, я работаю с яндес драйвером, перегрузить метод или класс мне кажется не такой сложной задачей, что никак не повлияет на другие jdbc только те отвалятся, что будут пилить работу с КХ в обход оф драйвера

лан полемика пошла, я понял, так исторически сложилось.

вот качаю я драйвер КХ и подключаю его в metabase или dbeaver которые написаны задолго до КХ и все работает. Потому dbeaver работает по спецификации jdbc API где колонки с 1. Иначе это безумие какое-то, зачем нужна спецификация. Нафиг тогда вообще JDBC

ок

День добрый. А подскажите какой string выберет кликхаус в конечном итоге?
Это SummingMergeTree

смотрите есть разные LAYOUT для словарей

но в общем случае воспринимайте словарь, это как большой cache в памяти, адаптированный для dictGet функции, который в зависимости от LAYOUT либо весь source грузил либо частично

там есть MIN \ MAX время когда словарь будет живой и когда он сам пытается обновиться

есть SYSTEM RELOAD DICTIONARY запрос для принудительного обновления
и есть SELECT * FROM system.dictionaries чтобы статус словаря поглядеть

словарь не может быть БОЛЬШОЙ в лучшем случае сотни тысяч активных элементов
потому что по факту это key value в памяти. на вход ключ словаря в виде tuple на выходе какой то атрибут, O(1) доступ по памяти... очень удобно когда надо связать таблицу фактов c таблицей измерений по схеме звездочка/снежинка

string в SORTING KEY входит?

Нет

В документации сказано, что выберутся случайные значения string в этом случае, но на данном примере кликхаус выбрал значение первой вставленной строки

Просто интересно можно ли использовать строки в SummingMergeTree, боюсь что строки могут теряться при слиянии

гарантии нет никакой, в документации сказано правильно

если поле не включено в ORDER BY или в PRIMARY KEY
то его считай что нет, выберется как захочет
вообще в summingMergeTree такие поля (по которым нет суммирования и которые в sorting или в PK не включены) IMHO не нужны

СТРОКИ в SummingMergeTree использовать МОЖНО как и любой другой тип
вы алгоритм суммирования поймите просто и все

берутся все поля которые в SummingMergeTree перечислены
дальше суммируются по одинаковым значениям sorting key
либо при background merge (после вставки)
либо при SELECT ... FINAL

выборку из summing merge tree лучше с FINAL делать, только  если вы дополнительно не делаете GROUP BY ...

Благодарю, перенесу строки в обычный merge tree

вот кстати забавный кейс... Final каким-то образом вместо 150 выводит отрицательное значение

SHOW CREATE TABLE test;
покажите