Не увидел в мануале упоминаний об ограничениях 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 заданной строки, у меня получилось так.
А с чем затруднение? Подцепить коммутатор к lan порту маршрутизатора. Модель роутера вы не назвали, но раз там уже 3 устройства есть - то вероятно роутер каких большинство с 4 lan и 1 wan.
Хотя кому эта полоса нужна?.. Вы должны делать что-то интересное, чтобы вас волновали seqscan/seqwrite, а не random i/o, которым и до 3.0 х1 далеко ещё