А проблема отсюда какая?

Ок, спасибо! Не заметил этот issue изначально

а есть примеры для 3?
или имелось ввиду в основной asc сортировка во второй desc и все?

всем привет. может кто-нибудь знает на сколько сильно может страдат производительность КХ на ядрах 2009 года

сейчас пришел запрос в КХ

SELECT object_content, object_type 
from objects 
WHERE pubDate between '2018-07-01' and '2020-07-09' 
group by object_content, object_type 
having uniqMerge(c) > 600
limit 100
FORMAT JSON

Нисколько

может тогда запросы надо оптимизировать

и вот такой еще  

SELECT distinct object_content, object_type
from objects
WHERE pubDate between '2018-07-01' and '2020-07-09'
 FORMAT TabSeparatedWithNamesAndTypes

ну а вообще вам зачем таблица в другой сортировке?

нифига себе фича, вот спасибо, что только не придумают )

Много различных фронтовых фильтров, которые в рамках одной таблицы будут работать крайне хреново из-за отсутствия индексов на полях
С другой стороны добавление INDEX в таблицы сильно режет скорость вставки, на столько сильно что эффективнее продублировать часть данных с нужным ключем в отдельной таблице

Класс. Я ничего не понял.

🙂

тогда сейчас пример организую 🙂

если селективити запросов низкий, работать с prewhere будут ок...

@den_crane

Условная таблица.
Поиск по любой колонке, asc/desc сортировки по любому полю

CREATE TABLE test_table (
  `childId` LowCardinality(String),
  `parentId` LowCardinality(String),
  `views` Int64,
  `clicks` Int64,
  `startedAt` DateTime,
  `finishedAt` DateTime,
  `isLive` UInt8,
  `isAdult` UInt8,
  `language` String
) ENGINE = ReplacingMergeTree() PARTITION BY substring(parentId, 1, 2)
ORDER BY
  (childId, parentId) SETTINGS index_granularity = 512

Наверно имелось ввиду добавление skipping indices без использования первичного ключа в поиске

хм, у меня просто есть запросы которые КХ в 100% грузят и к нему уже не сделать другие запросы. Кластер состоить из 4 ВМ на VMWare с 16 ядер, I/O без нагрузки

В логах реплик сейчас появились инсерты с данными за 25 и 26 число. Проверили селектом, за эти даты растут данные. Можете пояснить как работает репликация? Я считал, что данные попадают на мастер реплику, после чего происходит копирование на slave реплики асинхронно в фоновом режиме. Странно то, что select не находит новые данные, за сегодняшнее число, ни на одной из реплик.

подскажите, как скомпилировать КХ с использованием MySQL ?
select * from system.build_options
возвращает USE_MYSQL пустым