Печально. Раньше аргументировали своё решение тем, что оно "быстро и надёжно", сейчас тем что "модно и молодёжно". Ну типа штанов с промежностью на уровне колен. И все эти танцы с бубнами и определение таблиц через java annotation чтобы было кому отвечать на http запросы. На которые уже можно повесить JS интерфейс. Получается если научить SQL сервер напрямую отвечать на http запросы, какой-нибудь бездумный плагин, который бы автоматический конвертил http в SQL и обратно, то все эти модно-молодёжные технологии будут не нужны. Можно будет по старинке писать процедуры, которые работают внутри транзакций.

Хочу поблагодарить вас за ваши комментарии. Это сподвигло меня еще раз поискать способ, как сделать так чтобы и ошибок не было и чтобы база нулями не забивалась для бездействующих баз данных. И, оказалось, в Zabbix есть этот функционал, сложность была только его найти. Шаблон в конце статьи переписал на новую версию.

И возможно вы не прочитали мой предыдущий ответ. 6 параметров это нормально и ошибки выдавать не должно. :)

А, это не баг, а фича. Я писал об этом в статье. Сейчас напишу еще раз, подробнее. Конечно, всегда есть запросы в любую базу, например от заббикс, но я же их отрезаю. Поэтому, если в базе нет нагрузки, то и запросов в pg_stat_statements нет. И данные при запросе не возвращаются в заббикс. Тут есть два варианта, как тут поступить. Один из них - как реализовали вы, вставлять в таком случае пустые значения вместо текстовых данных и 0 вместо цифровых. В этом случае база заббикса будет заполняться строчками содержащими нули и пустоту для простаивающих баз. Второй вариант, это оставлять такие данные null, которые заббикс не понимает и выдает ошибку. Но в таком случае строчки в заббикс попросту не появляются. Такое будет для тех "простаивающих баз" у которых в течении суток не было ни одного запроса. Например базы postgres. Идеальным было бы найти такое значение для этого случая, чтобы и сообщений об ошибке не было и ненужные строчки в базе заббикса не возникали.
Мне мой вариант показался предпочтительнее, чтобы сэкономить место в и так большой базе данных заббикса. Но если это вам портит ощущение прекрасного, можете исправлять. Нет нужды это править в SQL запросе, он всегда отрабатывает нормально и там вы можете выскочить за предел максимальной длины запроса. И нормально все это попадает в json поле. Можете временно включить его запись в историю, чтобы видеть, как он выглядит. Ошибки возникают в depended item, которые забирают данные из json и преобразуют в числа. Если бы такое делал я, то я бы это делал где-то в разделе preprocessing у соответствующих item.

Смотрите <аргументы...> подразумевает, что их может быть несколько. :) А может быть ни одного. В custom query такой же механизм как и в UserParameters. Может быть любое количество аргументов, которые потом подставляются в нужные места запроса.

Обратите внимание. Вот есть два мнения. У нас базы данных для общего пользования ставятся на железе. Конечно, если нужно было тестировать какую-то экзотику, я ставил их у себя в виртуалках. И я могу свидетельствовать о том, что базы работают стабильно если не годами, то точно месяцами, пока не будут перезагружены, например, для обновления или изменения конфига (добавить модули). Да, бывают проблемы с ошибками веб программистов, но сам postgresql работает стабильно, без нареканий. (За исключением ранних 9.6 версий).
А есть второе мнение, о том как это хорошо и правильно ставить их в виртуалках. И этот же самый сисадмин сетует, что якобы PostgreSQL "заблокировал все записи" и "захапал коннекты", хотя postgresql захапать коннекты никак не может. Если только речь не идет о связи между двумя БД, типа логической репликации, fdw, dblink и т.д. Такое совпадение, что PostgreSQL работает нестабильно именно у того сисадмина, который считает правильным ставить его в виртуалках, говорит о том что проблема вовсе не в PostgreSQL, а либо в виртуалке либо в сисадмине. Highly likely последнее, потому что по симптомам больше похоже на тривиальную жопорукость. У нас было что-то вроде дублирования сетевых пакетов в Кубернетис, но тут другое.

Поставил дизлайк. Потому что все ваши аргументы построены на демагогии и оскорблении личности. Ничего, буквально ни одного аргумента вы не привели, который стоило бы обсудить. Все что вы написали характеризуется вашими же словами "Типичный бессознательный бред". Сплошные эмоции, без капли здравого смысла. Например фраза "Буквально неделю назад 15.4 остановил все записи, нахапал коннекшнов до лимита, и его пришлось убивать ручками." говорит о том, что вы в принципе не понимаете ни того как работает база данных, ни то как надо диагностировать или исправлять ошибки. Это не сервер PostgreSQL "хапает" коннешины, а наоборот, приложение. Вы даже не поняли что является источником проблемы, как следствие даже не пытались обнаружить её и исправить. И проблема с коннекшинами, точно такая же, ждёт вас еще не раз. И главный ваш талант это врать начальству, что это виноваты не вы, а PostgreSQL. Видимо, пока у вас это делать получается.
И раз вы не понимаете даже такие элементарные вещи, то эта статья не для вас. Обратите внимание, что уровень сложности выставлен как "сложный".

А так вы сейчас пишите про девелоперовский контур. Тут я вас поддерживаю, кстати. Я считаю что у каждого разработчика должна быть своя БД для отлаживания разработки. И я себе всегда такую делал. Впрочем и от общих баз данных для разработки тоже есть польза, в них объединяется труд разных разработчиков и окончательно проверяется перед выкаткой в продакшин. И с них я делал себе копию, если разрабатывал что-то своё.
А основная идея этой стати была в том, что бы такой мониторинг повесить именно что на продакшин с целью чтобы у разработчиков был доступ к информации о проблемах производительности и проблемных запросах на продакшине.

Типичная манипуляция общественным сознанием, использование слово "совковый", хотя оно тут совершенно неприемлемо. Современные средства виртуализации и конвейнеризации настолько глючные, что большинство поломок приходится именно на них. Сам по себе PostgreSQL очень стабилен и с самим PostgreSQL как с софтом никогда не бывает проблем, если только он не размещен на средствах виртуализации и конвейнеризации.
Более того. Отказоустойчивость веб сервисов основана на том, что в самих контейнерах не должно быть никакой информации относящейся к состоянию системы. Прочитайте, это в любом учебнике написано. Поэтому в случае выхода одного контейнера из строя или узла, легко можно поднять запасной. Это достигается как раз тем, что вся информация о состоянии системы находится в базах данных, например на базе PostgreSQL, а вот они находятся как раз не в контейнерах и их отказоустойчивость достигается другими методами.
Плюс потери производительности при виртуализации. Про потерю надежности уже говорил. Ну и, конечно, вопрос денег. Если молятся на модную микросервисную архитектуру это означает что баз данных очень много, но они небольшие и по сложности и по объему. У нас в компании несколько сотен баз данных. Арендовать под каждую виртуалку на точке обмена трафиком это еще и накладно, как по деньгам, так и по потерям производительности. Базы на железных машинах.

Поставил лайк, за то что использовали "постгрес", а не "постгря". :) Фраза "обновляйте ваши постгрясы" даже в голове не укладывается. :)

Ага, выглядит похоже.

Да, неплохой вариант, я забыл его упомянуть. Единственный его недостаток, что приходит в голову, то что эта функциональность появилась относительно недавно, а с проблемами сталкивался и в более старых версиях, где этой функциональности нет. Там помогает создание индекса по вычисляемому значению типа:
create index on test((j->>1));

А не надо от него отказываться. :) Он может быть полезен. И поскольку веб программисты очень часто используют json для своих собственных нужд удобно хранить данные тоже в json, чтобы не заморачиваться преобразованиями туда-сюда. Но если по каким-то полям json происходят частые запросы, тогда их имеет смысл оптимизировать. Например создавая специальные индексы для поиска по этим полям или, например, выносить их в таблицу в виде вычисляемого поля или еще как. Небольшие json работают не так уж плохо, никто не жаловался. :) Проблемные json обычно очень длинные.

Ну смотри, тут надо разбираться, почему так произошло. Первое что мне пришло бы в голову проверить, это при каких user_id такое происходит. Например, я сталкивался с ситуацией, когда планировщик отказывался от использования индекса, если значение находилось среди most_common_vals, но использовал индекс для поиска для всех остальных значений.