С инженерной точки зрения - проще купить какой-нибудь 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, я это не могу комментировать. Это ваш стиль ведения бизнеса. Должна быть заинтересованность в коллаборации. Если ее нет - то наверное и это партнерство не нужно.
самый правильный путь - это задавать уточняющие вопросы "по адресу". А то здесь понадают советов.
Будешь принимать за чистую монету а потом ходить и рассказывать что это чистая правда.
JWE описана в RFC и там вроде даже есть примеры. Но ее надо вычитать не с целью садиться кодить
а с целью снова задать вопросы техподдержке партнера.
Если задание слишком большое и сложное - то его бьют на части. На подзадачи или investigations где вопрос - крайне прост. Например:
- как получить аргументы комадной строки на nasm
- как работать с 7 ричной системой в nasm
- как вывести и отформатировать результат в nasm
Вот. Так. И только таким образом решаются сложные и непонятные задачи.
Есть диалект json-path. Значит можно обращаться к атрибутам и смотреть их атомарные значения. Дальше - дело техники. Кастить в числовые типы или типы дат-времени.
Сам по себе JSON-type не запрещен в DBMS. Можете пользоваться. Но его обычно имеет смысл применять там где есть требование вливать в базу "документы которые не специфицированы". И далее - делать по ним какие-то запросы.
Альтернативный вариант по слабой спеке - использовать модель EAV. Но EAV настолько неудобен в практическом применении что JSON является прямо-таки здравым решением если так сравнивать.