почему "странно"? Найдите диапазон с проблемными данными, бинарным поиском придите к конкретным данным и посмотрите что такое неожиданное вы записали. В этом и есть суть - найти некорректно-записанные данные.
Вы не уверены, а я - уверен. Что делать будем? Может быть проверите?
В исходным данных дважды закодированный 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 достать информацию об изменяемой в данный момент строке.
galaxy, если подставит литерал - то, в основном, такое только замедлит планировщик ненужной никому работой. А вот если там extended protocol с parse/bind/execute последовательностью - то запросто будут фокусы. Особенно вокруг переключения custom или generic планов.
Не надо пытаться запутывать планировщик. Он умный, но он тупой. Потому что ему нужно работать быстро, а не пытаться угадывать что же хотел сказать автор. Довольно много "оптимизаций" планировщика отклоняется именно по этой причине - мы не хотим замедлять абсолютно все запросы (некоторые и так планируются дольше чем собственно исполняются) чтобы исправлять один изначально странно написанный запрос.
Весьма не соглашусь, что "красивый синтаксис" в вашей идее, а не наоборот, в рядовом построении динамичного sql. Клиент запросил фильтр? Отлично, добавили его к sql запросу и сохранили параметр для bind. Просто, понятно, легко отслеживается, нет магических констант, которые как бы передаются параметрами, но игнорируются, легко планируется базой без фокусов, налагаемых ограничениями prepared stmt.
Да, собирать запрос по частям оптимально. Всевозможные query builder есть даже.
см. Serial ATA port multiplier чтобы понять глубину вариативности вопроса когда важен объём, а не пропускная способность.
Поищите описание серверов backblaze
shared_blks_read - только про отсутствующие блоки в shared_buffers. Узнать, дошёл ли запрос до диска или был из системного page cache выполнен - никак. Поэтому однозначно не сказать, что не хватает памяти. Ну разве только у вас больше 75% ram отдано под shared buffers, когда в системном page cache мало что может уместиться.
Тем не менее факт говорит о том, что половину суммарного времени выполнения этих 100тыс запросов ждали IO. 1мс латентности, конечно, не предел мечтаний.
Дальше пока наблюдать, ждать проблемный пик и смотреть как изменятся цифры.
auto_explain для этих запросов ведь не фиксирует изменение плана?
У меня нет примеров из практики, где необходим именно using hash.
Заведомо известно, что для hash нужны условия только на строгое сравнение, разнообразность входных данных. Желательно входные данные побольше 4 байт размером, иначе на 4-байтовых значениях хэш-функции мы будем только расти в размере.
Ну, например, из недавнего, табличка со статистикой запросов к базе по дням. Тексты запросов часто каждый день одни и те же, потому выношу их в отдельную таблицу-словарь и экономлю прилично места на диске. Нужно уметь при записи свежей статистики искать, был ли такой текст запроса ранее. При том, текст запроса может быть слишком длинным, чтобы умещаться в btree. Вот здесь уместен hash индекс. Но вполне может посоревноваться и btree поверх какой-нибудь хэширующей функции.
Да, btree более универсален.
До postgresql 10 пользоваться hash было вообще невозможно, не логировались в wal и потому не реплицировались, не crash-safe. В 10 переделали. По размеру на самом деле тоже спорно, надо проверять на конкретных данных. Видел ситуации, где hash по объёму как btree получается. Ну и дедубликация btree в pg13 весьма хороша.
хмхм. А у вас pg_dump точно от этого форка postgresql вызывается?
На вид похоже, что сама база у вас отдельный форк для 1с, на самом деле не умеющего работать с postgresql. Но pg_dump записал создание этих нестандартных типов данных. При том, судя по "there are 2 candidates for ... function" - они ещё и различаются между тем что в дампе и тем что нагородили в этом форке.
Если у вас на самом деле установлено несколько разных pg_dump и теперь вызывается не тот модифицированный для форка, а, например, от оригинального немодифицированного postgresql - то это может объяснить происходящее.
