Откуда такой вывод? Вы отправляете в канал либо hi, либо close. В switch и то, и другое обрабатываете. default сработает, если отправите что-то отличное от hi и close
В любом случае надо будет подождать, пока отревьвят и вмержат код из первого PR. До этого момент вполне можно ответвиться и сделать другой PR. После того, как вольют первый в мастер, коммиты первого PR из второго пропадут. Не вижу проблемы
Опять этот медленный Python! Выкиньте, и перепишите на Go
А если серьезно, вы конкурентно запускаете обработку или последовательно? Если конкурентно, то ясно, что будет медленнее, из-за постоянного переключения контекста
Константин, если у вас InnoDB, то как уже писал выше, первичный ключ в таблице создаст сам MySQL, но вы его видеть не будете. Индексы скорее увеличивают скорость доступа, если их правильно использовать, но уменьшают скорость добавления записей
Константин, Если есть уникальное поле, то можно сделать его первичным ключем. Также если у вас есть уникальный набор полей, то можно тоже сделать этот набор первичным ключем. Но тут есть проблема, если вам понадобиться ссылаться на эту таблицу из другой это будет неудобно и стоит подумать все таки об отдельном первичном ключе. Если вы не создаете первичный ключ явно, то MySQL создаст первичный ключ самостоятельно, но вы его видеть не будете. Поэтому первичный ключ в таблице есть в любом случае, но задавать его явно не требуется, хоть и предпочтительнее делать так
