а, ок

да, спасибо, так сделали

Можно из ключа сортировки поле удалять? И добавлять новое

ALTER ключа сортировки — лёгкая операция, так как при одновременном добавлении нового столбца в таблицу и ключ сортировки не нужно изменять данные кусков (они остаются упорядоченными и по новому выражению ключа).

выше писали только что изменение порядка ключа сортировки - сомнительная затея

version()
20.8.5.45
userlogin@host:~$
userlogin@host:~$ clickhouse-client -h host  -q "SELECT value FROM system.settings WHERE name LIKE 'input_format_null_as_default'"
1
userlogin@host:~$ clickhouse-client -h host  -q "truncate table t"
userlogin@host:~$
userlogin@host:~$ clickhouse-client -h host  -q "select * from t"
userlogin@host:~$
userlogin@host:~$ cat qqq
1       \N
2       0000-00-00 00:00:00.000000000
3       \N
4       2010-12-12 12:12:12.123123123
userlogin@host:~$
userlogin@host:~$ cat qqq | clickhouse-client -h host  --query="INSERT INTO t (s,dt64) format TSV"
Code: 27, e.displayText() = DB::Exception: Cannot parse input: expected '\n' before: '00:00.000000000\n3\t\\N\n4\t2010-12-12 12:12:12.123123123\n': (at row 1)

Row 1:
Column 0,   name: s,    type: UInt8,         parsed text: "1"
Column 1,   name: dt64, type: DateTime64(9), parsed text: "<BACKSLASH>N"ERROR
Code: 117, e.displayText() = DB::Exception: Unexpected NULL value of not Nullable type DateTime64(9) (version 20.8.5.45 (official build))

, Stack trace (when copying this message, always include the lines below):

0. Poco::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) @ 0x18bb6380 in /usr/bin/clickhouse
1. DB::Exception::Exception(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) @ 0xe60c32d in /usr/bin/clickhouse
2. ? @ 0xe64f5d2 in /usr/bin/clickhouse
3. DB::TabSeparatedRowInputFormat::readRow(std::__1::vector<COW<DB::IColumn>::mutable_ptr<DB::IColumn>, std::__1::allocator<COW<DB::IColumn>::mutable_ptr<DB::IColumn> > >&, DB::RowReadExtension&) @ 0x1644f36b in /usr/bin/clickhouse
4. DB::IRowInputFormat::generate() @ 0x16350d31 in /usr/bin/clickhouse
5. DB::ISource::work() @ 0x162ccbdb in /usr/bin/clickhouse
6. DB::InputStreamFromInputFormat::readImpl() @ 0x1628fe2d in /usr/bin/clickhouse
7. DB::IBlockInputStream::read() @ 0x154668bd in /usr/bin/clickhouse
8. DB::ParallelParsingBlockInputStream::parserThreadFunction(std::__1::shared_ptr<DB::ThreadGroupStatus>, unsigned long) @ 0x16294280 in /usr/bin/clickhouse
9. ? @ 0x16294f04 in /usr/bin/clickhouse
10. ThreadPoolImpl<ThreadFromGlobalPool>::worker(std::__1::__list_iterator<ThreadFromGlobalPool, void*>) @ 0xe63a637 in /usr/bin/clickhouse
11. ThreadFromGlobalPool::ThreadFromGlobalPool<void ThreadPoolImpl<ThreadFromGlobalPool>::scheduleImpl<void>(std::__1::function<void ()>, int, std::__1::optional<unsigned long>)::'lambda1'()>(void&&, void ThreadPoolImpl<ThreadFromGlobalPool>::scheduleImpl<void>(std::__1::function<void ()>, int, std::__1::optional<unsigned long>)::'lambda1'()&&...)::'lambda'()::operator()() const @ 0xe63adaa in /usr/bin/clickhouse
12. ThreadPoolImpl<std::__1::thread>::worker(std::__1::__list_iterator<std::__1::thread, void*>) @ 0xe639b47 in /usr/bin/clickhouse
13. ? @ 0xe638093 in /usr/bin/clickhouse
14. start_thread @ 0x76ba in /lib/x86_64-linux-gnu/libpthread-2.23.so
15. /build/glibc-LK5gWL/glibc-2.23/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:111: clone @ 0x10741d in /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.23.so
(version 20.8.5.45 (official build))
Code: 27. DB::Exception: Cannot parse input: expected '\n' before: '00:00.000000000\n3\t\\N\n4\t2010-12-12 12:12:12.123123123\n': (at row 1)

Row 1:
Column 0,   name: s,    type: UInt8,         parsed text: "1"
Column 1,   name: dt64, type: DateTime64(9), parsed text: "<BACKSLASH>N"ERROR
Code: 117, e.displayText() = DB::Exception: Unexpected NULL value of not Nullable type DateTime64(9) (version 20.8.5.45 (official build))
userlogin@host:~$
userlogin@host:~$ cat qqq | clickhouse-client -h host --input_format_null_as_default=1  --query="INSERT INTO t (s,dt64) format TSV"
userlogin@host:~$
userlogin@host:~$ clickhouse-client -h host  -q "select * from t"
1       2021-01-21 04:40:02     1970-01-01 00:00:00.000000000
2       2021-01-21 04:40:02     1970-01-01 00:00:00.000000000
3       2021-01-21 04:40:02     1970-01-01 00:00:00.000000000
4       2021-01-21 04:40:02     2010-12-12 12:12:12.123123123

You save my life out of debt and I don't think I could ever repay you for all that you have done for me, I will keep telling people about your good work you have done in my life. Now get your self a Bitcoin wallet and get it fund with any amount of a startup capital and  Inbox him now to earn  true the link ⤵️⤵️⤵️⤵️

https://t.me/joinchat/TyRIWiGnsE39MwK3

[ODBC Data Sources]
clickHouse = clickHouse

[clickHouse]
Driver    = /opt/clickhouse-odbc-1.1.9-Linux/lib/libclickhouseodbc.so
server    = xxxxxxxxxxxxxx
username  = ananth
password  = xxxxxxxx
port      = 8123
database  = ananthdm
uid       = ananth
# sslmode = allow
trace     = 1
tracefile = /opt/clickhouse-odbc.log

after specifying the specific database name it allowing all database for the users

is there any configuration changes in user.xml fil e

Всем добрый день! dBeaver не возвращает результаты explain select в clickhouse. Кто-то знает возможность убедить его возвращать? или может посмотреть результаты где-то в другом клиенте?

Всем привет, подскажите как работает внешний справочник? Например я подключил справочник из постгри, там табличка из 1-3кк записей. КХ поидее раз в какое-то время обновляет этот справочник. Получается он каждый раз гоняет вообще все данные из таблицы, вытаскивает и все перезаписывает или как-то работает только с новыми данными и частично удаляет?

Полностью гоняет.

А то что там 3кк данных, это ниче страшного?

Для словаря пофик. Но сам словарь в памяти держится, если у вас её много, то все норм.

Понял, спасибо!

https://clickhouse.tech/docs/ru/sql-reference/dictionaries/external-dictionaries/external-dicts-dict-lifetime/
полностью, но в некоторых случаях только в случае наличия изменений

Там обновляется полностью, но только если invalidate query другой ответ вернул. Где-то пролетало, что какой-то движок (конкретная СУБД) может только изменения присылать, но где это видел-слышал - не помню. А может это вообще звон из другой деревни.

движки https и executable позволяют ходить в словарь только по запрашиваемым ключам.