Да, я исходил из предположения, что в таблицу сохраняются данные каждый день для всех, у кого exp != 0. Если какого-то дня не было - значит пользователь на тот момент не был зарегистрирован вообще или имел 0 exp.
Для таблицы такого плана, да если ещё и партицировать - и сотни миллиардов строк фигня. Зато считать проще и быстрее.
CURRENT_DATE - странно, но да, мог чего-нибудь напутать.
Вполне. Могут быть вариации, но суть схожа. Например, система А отправляет событие, система Б генерирует id транзакции. Следом система Б обращается к системе А с вопросом: вот по такой-то транзакции запрос выполнять? Соответственно, А может удивиться "не знаю такую транзакцию"
Есть огромный бонус в том, что архитектурно предусмотрена суровая реальность - что делать, если система Б случайно упала. Ничего не делать, как поднимется - так и получит штатно все пропущенные сообщения.
Но это всё-таки сценарии не атомарные. Некоторое небольшое время Б может быть закоммичено, а А - ещё в процессе или наоборот. Eventual consistency т.е.
Если нужно именно закоммитить распределённую транзакцию - то посмотрите в сторону двуфазного коммита. Помнится, там ворох своих граблей.
Лучше пишите комментарий к ответу, а так я только случайно заметил ответ.
Сообщение об ошибке полностью форматирует сишный код. Там проблем с 64-битными целыми и не было. А вот переменные под виндой - только как 32-битные компилировались, в PHP7 с глобальным улучшением движка поправили.
Да, по идее near2 должен оставаться живым при выпадении любых не соседних дисков.
У вас проблема именно с загрузкой? Если на ходу сфейлить диски - то нормально себя массив ведёт, не разваливается?
/boot у вас на этом же массиве? Себе я размечаю /boot отдельным зеркалом по всем дискам. 100-200мб не жалко полностью отзеркалировать.
Или нормальный аппаратный с кэшом и батарейкой или нормальный программный.
Если брать аппаратный рейд - то могут быть какие-то фокусы. Правда, насколько мохнатых годов надо брать контроллер для этого - я хз. Но допускаю возможность.
Если брать программный - то от материнки требуется только достаточной длины адресация LBA. LBA48 (диски до 128ПиБ, т.е.) стандартизировали ещё в 2003 году для ATA-6. Если ваша железка настолько древняя, как вы к ней sata диски собрались подключать?
Да и не помню, чтобы было что-то между LBA48 и LBA28
Инвалидироваться кэш будет на любой insert/update/delete таблицы. Т.е. кэш запросов к таблице Sms будет адекватно работать, только если админку открывают очень часто, а сама таблица изменяется очень редко. Т.е. картина, в корне отличная от вашей.
Если бы у вас была таблица новостей сайта, которые пишут полтора землекопа раз в день, а остальные делают только select - то query cache бы работал внятно.
А, винда. Проверьте на нормальной системе.
Как говорят опытные ДБА, postgresql - это только linux или freebsd.
На сколько помню по прошлой pgday'15, где этот вопрос вскользь звучал, на винде не работает shared memory - а это краеугольный камень всей архитектуры postgresql. Какими-то граблями шаренная память под виндой эмулируется чтобы хоть как-то запуститься, о производительности там речи не идёт.
В зависимости от способа кодирования. Но предельный размер именно в байтах, в байтах его и считайте.