YY
mailрушным httpшным не занимаются
tcpшным не занимаются
эдак по миру пойдем☹️
tcpшным не занимаются
эдак по миру пойдем☹️
mailрушным httpшным не занимаются
tcpшным не занимаются
эдак по миру пойдем☹️
Size: a a a
2021 March 25
S
ну скажем так, мантейнеры обоих драйверов работают уже в других областях
и чтобы они вмержили их надо пинговать и чтобы PR был хороший с тестами
и чтобы они вмержили их надо пинговать и чтобы PR был хороший с тестами
YY
да-да, однажды я уже протолкнул ПР Кириллу, попробуем повторить)
T
это с engine=Log ?
Залил в engine = Log, залилось столько сколько должно быть
DC
Залил в engine = Log, залилось столько сколько должно быть
чудеса. У таблицы MergeTree точно движок MergeTree а не ReplacingMT ?
T
ага, у таблицы такие хар-ки
ENGINE = MergeTree
PARTITION BY toYYYYMM(start_timestamp)
PRIMARY KEY start_timestamp
ORDER BY (start_timestamp, record_type)
TTL start_timestamp + toIntervalDay(731)
SETTINGS index_granularity = 8192
ENGINE = MergeTree
PARTITION BY toYYYYMM(start_timestamp)
PRIMARY KEY start_timestamp
ORDER BY (start_timestamp, record_type)
TTL start_timestamp + toIntervalDay(731)
SETTINGS index_granularity = 8192
T
всё это дело происходит в рамках одного экземпляра
T
я раннее указывал в этой клиент сессии set read_backoff_min_latency_ms=0, это может хоть как-то повлиять? Мб с этой опцией mergetree попробовать залить
KS
ага, у таблицы такие хар-ки
ENGINE = MergeTree
PARTITION BY toYYYYMM(start_timestamp)
PRIMARY KEY start_timestamp
ORDER BY (start_timestamp, record_type)
TTL start_timestamp + toIntervalDay(731)
SETTINGS index_granularity = 8192
ENGINE = MergeTree
PARTITION BY toYYYYMM(start_timestamp)
PRIMARY KEY start_timestamp
ORDER BY (start_timestamp, record_type)
TTL start_timestamp + toIntervalDay(731)
SETTINGS index_granularity = 8192
в порядке бреда - у вас при вставке не может быть так что TTL отрезает вот эти 10%?
T
в порядке бреда - у вас при вставке не может быть так что TTL отрезает вот эти 10%?
┌─max(start_timestamp)─┬─min(start_timestamp)─┐
│ 2019-10-31 23:59:59 │ 2019-03-25 15:07:21 │
Прямо сегодня можно сказать, что часть записей усекается, дня 3-4 назад было также
│ 2019-10-31 23:59:59 │ 2019-03-25 15:07:21 │
Прямо сегодня можно сказать, что часть записей усекается, дня 3-4 назад было также
T
┌─max(start_timestamp)─┬─min(start_timestamp)─┐
│ 2019-10-31 23:59:59 │ 2019-03-25 15:07:21 │
Прямо сегодня можно сказать, что часть записей усекается, дня 3-4 назад было также
│ 2019-10-31 23:59:59 │ 2019-03-25 15:07:21 │
Прямо сегодня можно сказать, что часть записей усекается, дня 3-4 назад было также
Попробую с расширенным ТТЛ залить также в mergetree
KS
попрбуйте вообще без него, чтоб уж наверняка)
T
попрбуйте вообще без него, чтоб уж наверняка)
ок) его то всегда можно задать)
DC
ок) его то всегда можно задать)
так на источнике select count() ... where start_timestamp < now() - toIntervalDay(731)
T
так на источнике select count() ... where start_timestamp < now() - toIntervalDay(731)
есть записи, но кажется сейчас корректно тяжело вытащить, т.к. ТТЛ уже наступает на таймстемп
Я сейчас уже заливаю без ТТЛ в mergetree
Я сейчас уже заливаю без ТТЛ в mergetree
T
Попробую с расширенным ТТЛ залить также в mergetree
ТТЛ я убрал совсем, но всё равно есть разница, в исходной таблице 358 648 861, в конечной 358 960 865
DC
ТТЛ я убрал совсем, но всё равно есть разница, в исходной таблице 358 648 861, в конечной 358 960 865
теперь больше чем было?
KL
Всем привет! Подскажите, как объяснить следующий результат селекта?
create table Test (StartTime DateTime) engine = Memory;
insert into Test (StartTime) values (2020-01-01);
select StartTime from Test;
2105-06-18 11:19:55
create table Test (StartTime DateTime) engine = Memory;
insert into Test (StartTime) values (2020-01-01);
select StartTime from Test;
2105-06-18 11:19:55
T
было до этого:
в исходной 358 960 865
в конечно 358 681 260
в исходной 358 960 865
в конечно 358 681 260
KL
Тут допущена ошибка в values, пропущены кавычки