Вот это условие - никогда не выполняется if(chunk.chunkId == CT_data){
почему - фиг его знает. Надо за шаг до этой проверки получить логгирование chunkId и offset из читаемого файла.
И посмотреть внутрь самого файла. Соотвествует ли реальности.
А как сортировать мап? Просто я не очень хорошо его знаю
Тут - хитрость. Тебе вобщем-то не надо его сортировать. Тебе надо найти max из всей коллекции (мапы).
Напечатать его на экране. И еще по заданию написано что надо сделать поиск таких-же максималов.
Поэтому удаляем из мапы счастливчика и просто повторяем поиск max. И так далее пока количество голосов
совпадает.
Впрочем при случайном распределении голосов это маловероятно. Скорее всего счастливчик будет один.
И в тестовых кейсах возможно 2 или 3.
Если эти редкие кейсы все таки будут в тестировании твоего исходника - то возможно будет фейл по времени.
Тогда план Б - конвертить в heap. Где-то даже процедура такая есть хипи-зация. Heapyfy. Или makeHeap.
Она из коллекции делает квази-сортированный массив (куча или пирамида). И из него можно брать 2-3 счастливчика. Сохраняя свойство пирамиды.
С инженерной точки зрения - проще купить какой-нибудь HDMI-сплиттер и раздавать телевидение на кухню и в основную комнату.
Беря во внимание затараты вообще на разработку и на конфигурирование, я-бы посчитал этот способ самым дешевым в реализации.
Все другое будет либо ненадежным (надо саппортить самому не только одну единицу софта но и все его порты на все устройсва) либо просто дорогим в разработке. А у автора - настоящий зоопарк устройств. Вот как вы себе видите план по их поддержке? Я аж вообще никак. Тут иногда корпорации не могут поддержать несколько UI на Desktop и мобилы. А вы хотите в частном порядке.
Кстати премиальная подписка youtube. Нажал на паузу в телефоне. Перешел на кухню. И там нажал своё видео - и продолжаешь смотреть. Тоесть частично уже реализовано.
В 90х когда я учился в универе мы покупали жлобское железо. Например процессоры AMD K6. Были такие. Так вот у них был свой уникальный набор команд 3-DNow для игр как раз. К сожалению я не знаю в каких играх он применялся. Но факт есть фактом. У AMD было своё над-множество команд которых не было у Intel.
Могу сказать не по постгресу а по Ораклу. Но я думаю что инфа - релевантна. Использование индекса считается эффективным если выборка составляет от 3% до 7% datarows. В разные времена для разных версий эти цифры именялись. Это было справедливо в эпоху HDD.
Очень сильно на эту оценку влияет тип носителя где лежит индекс (SSD). Обычно SSD ведут себя лучше для IOPS.
А индексы - это какраз IOPS.
Очень сильно влияет следующее: достаточно-ли оптимизатору ТОЛЬКО информации из индекса (count) или ему еще надо ДЖОЙНИТЬ индексный элемент с табличным.
Ну и конечно - сбор статистики по таблицам. План. План и еще раз план.
Самый плохой кейс для оптимизатора когда вы танцуете на грани двух типов запросов : OLTP-Analytics. В этом случае у вас гарантийно будут плохие планы и чтобы их стабилизировать надо вбивать гвозди типа "хинтов" или каких-то DBMS-специфичных SQL конструкций кооторые могут например запретить хождение в индекс.
А грань эта может появлятся как-раз из-за объема выборки 100-100k-20mln. Оптимизатор в принципе не может
работать в один план по такой сильно разной природе запроса. Первая цифра - четко тяготеет к точечной выборке (индексы) а последний кейс - требует FTS.
Учитесь анализировать планы SQL. Без этого любая активность в оптимизации - это шаманство и игра в метод тыка.
Falseclock, я это не могу комментировать. Это ваш стиль ведения бизнеса. Должна быть заинтересованность в коллаборации. Если ее нет - то наверное и это партнерство не нужно.
