да, могли бы. Если бы не существовало частичных индексов - то сюда бы подошёл 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.
Отдельно из опыта разработчика как раз системы, завязанной на большое число сторонних API: сразу предполагайте, что API будут отвечать неадекватно и вам будут необходимы подробные логи уровня коммуникации сервисов: датавремя, какой запрос сделали к api, какой ответ получили. Если говорим о HTTP REST - то сохранять буквально весь HTTP request как он уходит текстом и сохранять весь пришедший ответ с заголовками, время отправки запроса, время получения ответа.
А в чём у вас затруднение? Не написать after insert триггер? Не сделать insert ... select from generate_series(1, NEW.devicecount, 1)? Или даже for loop?
В postgresql есть simple query протокол - идёт текстовый запрос и дальше развлекается база.
Есть extended protocol, состоящий из parse пакета со структурой запроса и метками под параметры, затем идёт один или несколько bind и execute пакетов. В bind передаются значения параметров, execute соответственно запускает выполнение запроса. В сам текст запроса актуальные значения параметров при этом никогда не вставляются за ненадобностью. Так же известный как server prepared statements api.
Это и есть query как оно пришло от клиента. Не уверен что можно дотянуться до соответствующих bind.
Но триггер же, можете из OLD и NEW достать информацию об изменяемой в данный момент строке.
