Привычка, сэр. Вот в руках один девайс, прослуживший много лет. Который работает одновременно и под хранение всевозможных данных (драйвера те же) и для загрузки пачки разных версий ОС, да ещё всякая загрузочная мелочёвка, на которую жалко целую флешку выделять (memtest банально - и не надо вспоминать, на каком дистрибьютиве он есть встроенный в лёгком доступе). Когда просто не думаешь, от чего придётся отказаться, чтобы закатать другой дистрибьютив, а берёшь и кладёшь исошку рядом.
Подписывать и переподписывать флешки? Запоминать что на какой флешке? Зачем, просто берёшь и переключаешь образ.
У меня VE-200, ещё с usb 2.0, с тех времён, когда при заказе легко было услышать "вы знаете, уже все разобрали, следующая партия будет через неделю, могу для вас зарезервировать"
Не увидел в мануале упоминаний об ограничениях pci-e режима, только про шаренный sata написано. Попробуйте аккуратно протереть контакты. Как 3.0 x4 согласно мануалу завестить должен
Хотя кому эта полоса нужна?.. Вы должны делать что-то интересное, чтобы вас волновали seqscan/seqwrite, а не random i/o, которым и до 3.0 х1 далеко ещё
Режим передачи PCI-E 3.0 x2 (985мб/с *2) вместо паспортного PCI-E 4.0 x4 (1.97гб/c * 4). То есть шина заведомо уже в 4 раза. Вполне похоже на предел шины.
ну, для начала сделайте выражения синтаксически корректными. Тогда может быть станет понятно, что вы подразумеваете под "в поле secret добавить новую функцию"
да, могли бы. Если бы не существовало частичных индексов - то сюда бы подошёл btree(status, date). Но такой индекс будет существенно больше частичного.
какие именно запросы? Что такое "разные условия"?
"where status = 'pending' order by date limit 20" и всегда только pending это совсем не то же самое, что поиск по любому статусу.
под "where file_name = ?" - полностью другая история и полностью другой индекс
По распределению данных: id уникален? А file_name? уникален? Сколько из ваших 50млн строк в каком статусе типично числятся?
Медленнее в общем случае. Треть таблицы быстрее будет прочитать seqscan'ом.
index scan'ом читать треть таблицы - это много скакать (по памяти или random i/o) сперва для индекса, потом для каждой найденной в индексе версии строки лезть в таблицу. Много беготни. Обычно база не будет использовать такой индекс.
А где вы видели, что фича появится в pg14? Я за этой темой не слежу, но и в pg15 я бы не ждал тоже. Долгострой, привлекающий очень мало внимания.
Если смотрите на Target version - то перестаньте туда смотреть. Единственная цель и причина появления этого значения - во время мартовского коммитфеста вежливо указать, что эту штуку можно отложить на потом.
Если вам интересен этот патч - прочтите ветку, скомпилируйте, протестируйте в каких-нибудь условиях, всё ли работает как ожидается. Может быть есть идеи по улучшению пользовательского взаимодействия с фичей? Большинство патчей топчутся на одном месте из-за недостатка review. Да, даже review от незнакомых с кодовой базой людей приветствуется. (пишу как контрибьютор)
покажите реальный sql запрос. Из лога базы, например, легко достаётся. По-видимому, вы конкатенируете значение напрямую в запрос и получаете from (values (63 933-339-99-97)) as p(n);
что, конечно, ничем кроме как ошибкой быть не может. Передавайте строку как строку.
почему "странно"? Найдите диапазон с проблемными данными, бинарным поиском придите к конкретным данным и посмотрите что такое неожиданное вы записали. В этом и есть суть - найти некорректно-записанные данные.
Вы не уверены, а я - уверен. Что делать будем? Может быть проверите?
В исходным данных дважды закодированный json. Может быть существует и попроще способ сделать json decode заданной строки, у меня получилось так.
Подписывать и переподписывать флешки? Запоминать что на какой флешке? Зачем, просто берёшь и переключаешь образ.
У меня VE-200, ещё с usb 2.0, с тех времён, когда при заказе легко было услышать "вы знаете, уже все разобрали, следующая партия будет через неделю, могу для вас зарезервировать"