На то они и модеры

ну, тут упрощенная схема без модераторов, хотя бы просто высылать хр туда, а тут банить после 1 предупреждения)

Я думаю, если народ/модераторы будут указывать hr-ам про @pgsqljobs, то все привыкнут к правилам и узнают про эту группу. Не хочется вводить формализм, кроме одного правила - здесь мы обсуждаем технические вопросы, модераторам и всем это понятно. Если хотите флудить, давайте сделаем pgsqltrep. У нас много новичков и им бывает тяжело ориентироваться в общем потоке, бывалые помогают, спасибо за это, но иной раз все выливается в хрень, что мной раз хочется злоупотребить. Кстати, в info о группе я добавил про это единственное правило и ссылку для hr-ов и жаждущих.

не, отдельный канал для флуда мне кажется уже перебор

Да мне тоже не хочется наводить формализм, как в некоторых местах. Наше сообщество отличается серьёзностью намерений. Пишите мне в личку, если у кого есть опыт или предложения для организации работы. Пока что я вижу, что нам очень не хватает фака для новичков.

В IRC есть и получается нормально (а там в пять раз меньше пользователей, чем здесь).
Но вопросы "около" postgres там всё равно нередко обсуждаются в основном канале, но только когда активных технических вопросов нет.

А как нам pool заделать, чтобы народ высказался ?

Как-то же можно делать poll-ы в telegram, нередко вижу (я нигде не модератор и поэтому не знаю, как)...
Но я за эту идею. ;)

чтобы сделать опрос, надо админу нажать на приложить (скрепка) и там есть poll. дальше по наитию

всем доброго вечера. хотел пустить приложение на Laravel через pgbouncer, но там используются prepared statements, и ничего не взлетело. Кроме отключения prepared statements в конфиге laravel, есть варианты ?

и бота сюда прикрутить. чтоб баны тут раздавал и жалобы собирал

Если выделять и без обсуждений, то и для ищущих легче

Есть sql-запрос, вызываемый из приложения (ниже представлен сильно упрощенный вариант с сохранением сути). На вход передаётся идентификатор документа первого уровня и массив натуральных ключей (допустим, опять же для простоты, что это связка имя-фамилия). Цель - найти идентификаторы документов третьего уровня, в связке с натуральными ключами, которые встречаются в переданном массиве. И вот эти конкатенации, касты к json и т.п. нереально тормозят запрос (если оставить те же join-ы одни, производительность возрастает в 20 раз) - можно ли с этим ужасом что-то сделать?

WITH keys AS (
 SELECT hstore( %2%::TEXT[], array_fill(1::text, array[0]) ) natkey
)
SELECT thrd_lvl_documents.id, concat(
  UPPER(COALESCE(thrd_lvl_documents.data::json#>'{employee}'->>'SecondName', '')) ||
  UPPER(COALESCE(thrd_lvl_documents.data::json#>'{employee}'->>'Name', ''))
  )AS nat_key
FROM
thrd_lvl_documents 
JOIN snd_lvl_documents ON thrd_lvl_documents.snd_lvl_doc = snd_lvl_documents.id
JOIN fst_lvl_documents ON snd_lvl_documents.fst_lvl_doc = fst_lvl_documents.id
JOIN keys ON keys.natkey->concat(
  UPPER(COALESCE(thrd_lvl_documents.data::json#>'{employee}'->>'SecondName', '')) ||
  UPPER(COALESCE(thrd_lvl_documents.data::json#>'{employee}'->>'Name', ''))
  ) IS NOT NULL
WHERE
fst_lvl_documents.id = %1%::bigint

pgbouncer в другом pooling mode.

Session?

WITH keys AS (
 SELECT hstore( %2%::TEXT[], array_fill(1::text, array[0]) ) natkey
)
SELECT thrd_lvl_documents.id, concat(
  UPPER(COALESCE(thrd_lvl_documents.data::json#>'{employee}'->>'SecondName', '')) ||
  UPPER(COALESCE(thrd_lvl_documents.data::json#>'{employee}'->>'Name', ''))
  )AS nat_key
FROM
thrd_lvl_documents 
JOIN snd_lvl_documents ON thrd_lvl_documents.snd_lvl_doc = snd_lvl_documents.id
JOIN fst_lvl_documents ON snd_lvl_documents.fst_lvl_doc = fst_lvl_documents.id
JOIN keys ON keys.natkey->concat(
  UPPER(COALESCE(thrd_lvl_documents.data::json#>'{employee}'->>'SecondName', '')) ||
  UPPER(COALESCE(thrd_lvl_documents.data::json#>'{employee}'->>'Name', ''))
  ) IS NOT NULL
WHERE
fst_lvl_documents.id = %1%::bigint

что-то пересокращали:
- не хватает SELECT
- не понятна конструкция `JOIN keys ON keys.natkey->concat(…`
- ну и надо бы EXPLAIN (analyze, buffers) чтобы видеть как тормозит

Да.

Select

добавил. JOIN keys ON keys.natkey->concat фактически, оригинальный перл автора данного запроса (на входе массив натуральных ключей кастится к hstore, а тут мы, получая очередную запись thrd_lvl_documents на месте выдёргиваем из данных куски, соединяем их воедино и проверяем оператором "->" наличие этих данных в hstore). Explain с замазанными названиями таблиц и полей вам что-нибудь даст?

Select

засуньте в explain.depesz.com, там есть анонимизация и удаление планов