Есть 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

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

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

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

https://explain.depesz.com/s/LJFc

За сайт отдельное спасибо - не знал про существование подобного ресурса с автоматической анонимизацией.

- оценка записей для romeo_charlie плывёт, надо проанализировать; - всё время тратите на фильтрацию при слиянии. может вместо того, чтобы городить эту конструкцию c keys, посмотреть на оператор @@ и jsonpath? или сделать проверку на вхождение массива [ SecondName, Name ] в ваши keys? чтобы перенести фильтрацию из JOIN-а в IndexScan.

С индексом romeo_charlie мне ничего и не дадут сделать, а вот второй и третий совет попробую копнуть глубже - спасибо за помощь.

это не индекс, а таблица. нужно ANALYZE сделать