ага

Вернее, вот так
RENAME TABLE data_flat.flat_temp TO data_flat.flat_temp_old

ALTER TABLE занимает некоторое место в очереди между обычными запросами, и в этом случае не дождался ее похоже

Я удалял данные из таблицы, вернее, переносил из одной в другую. Потом решил переименовать. А она ну  ни в какую. Даже с интервалом в несколько часов делал - думал, может, если какой процесс ещё не закончился

мх, вообще это означает. что клик не может взять лок на эту таблицу

можно попробовать рестартнуть сервис и быстро ее rename, или может DETACH ATTACH сделать таблицы

но скорее проще всего убрать запросы к ней:)
и зависит от того, какие у тебя есть возможности

Кстати, аттач/детач тоже не смог сделать - пишет ту же ошибку, только на READ. Собственно, поэтому и пришлось переносить в другую таблицу с изменённой структурой - не детачит и всё тут. Хотел расширить количество значений под enum, участвующем в партиционировании, изменив *.sql в метадате. Ну так вот, на мелких тестовых таблицах сработало, а на боевой огромной не получилось. Пришлось создавать новую с обновлённой структурой, а потом селектить/инсертить. Но старую, блин, даже пустую переименовать не могу (((

SELECT * FROM system.processes WHERE query LIKE '%data_flat.flat_temp%';

Посоветуйте как лучше сделать.
Есть 7 числовых фильтров - countryId, browserId, OsId и т.д.

Их все можно запихать битовой маской в uint32.
В реалиях КХ лучше сделать 7 отдельных колонок uint8 или одно поле с маской uint32 ?

Если важно - эти фильтры будут частью primary key.

Кроме страны, которая 8 бит, остальные фильтры от 1-го бита до 5.

Сорри за офф, очнадр

Привет.
Не подскажете, программа для такого кейса:
Есть mp4, штук 10 и минут на 30,
Надо на выходе получить одно видео, на 3 минуты и со своим аудиорядом.
Ну и без ватермарки и т.п.,
Желательно под убунту :-)

ffmpeg

7 отдельных колонок дают меньше гемора, но больше по памяти и диску... если данные влезают лучше не велосипедить. чтобы индекс полезней работал хорошо лучше сортировать по колонкам с низким кардиналити (ставить их вначале)

коротко говоря, вы не получите прирост в скорости или экономию места "на порядок", если будете мучать битмап...

ffmpeg

Al T @nyoroon
Спасибо большое!

Спасибо.
А вообще надо потестить для себя чтоб снять вопросы.
По диску разницы может особой и не быть из-за поколоночного сжатия, а вот в памяти при select'e (после распаковки) отдельные колонки должны больше занимать.

да, если не упираетесь, то оно того не будет стоить... ну и менять индивидуальные колонки проще чем битмапы

Пока никуда не упираемся, этап проектирования )
Ожидается до 100M записей в сутки в SummaryMergeTree.
Крутиться будет в облаке, диск можно расширять до определённых пределов (iops'ы тоже), ядер до 64-х на одном тазике.

Характер нагрузки - постоянная запись пачками десятков тысяч строк, относительно редкие чтения со сканированием в пределах 1M-100M записей.

В SummaryMergeTree первичный ключ 12 колонок (если эти фильтры отдельными столбцами делать). Отсюда и возник вопрос, может его урезать за счёт битовой маски.

В общем лучше протестировать разные варианты и на числа тогда смотреть.

можно разделить PK и ORDER BY
если часть столбцов нужна только для сортировки