Это учебная задача или нет?

А можно просто для общего развития-какую задачу вы вообще решаете столь экстравагантным способом?

Как же не волнует если пишу об этом, просто мы не можем понять друг друга. Задача: Я возвращаю одним запросом иерархический набор данных сущность и ее свойства. таблица а сущность. связанная таблица b (view) это свойства сущности. полное представление из пока 250 тысяч записей формируется порядка 5 секунд, что меня радиально не устраивает. ограниченное через функцию по массиву выборки до 500мс. Вроде хорошо, но реализация через массив выборки вызывает сомнения в плане возможных количественных ограничений при недопустимой ширине охвата не получу ли ограничений на количество элементов массива. Понятно что нормально составленное условие не должно дать таких результатов но оценить на данном этапе я не могу. как то так

> полное представление из пока 250 тысяч записей формируется порядка 5 секунд, что меня радиально не устраивает.

Да какая Вам разница, сколько оно формируется?! Вы же на практике добавляете в запросы к этому view какие-то условия, так?
Или же, если этот результат Вам нужен целиком — что, у Вас есть лучшая альтернатива?

> ограниченное через функцию по массиву выборки до 500мс.

А в Киеве — дядька. ;) Это же совершенно другая выборка!

> не получу ли ограничений на количество элементов массива

А на это я уже отвечал (мне даже кажется, что не один раз).

select B.id, A.id from B join A on A.id >= B.id and A.id < coalesce(LEAD(B.id) over (order by B.id), INT_MAX)
order by 1, 2
Что-то такое, гуглите LEAD/LAG

Имхо, ни один движок SQL не умеет такое оптимизировать (идти по 2 индексам параллельно). Умеют только идти по 1 индексу и дёргать второй. Вариант идти по B дёргать A выгоднее, если записей в А сильно больше

оставлю и академический вариант

select a.id as aid, b.id as bid
from a left join b on b.id = (select max(t.id) from b as t where t.id <= a.id)
order by 1;

А вот таки и есть разница. В отсутствие ранее упомянутой упреждающей выборки описание корой я обещал поискать и не отказываюсь от этого формировании без ограничений при простом связывании по JOIN с view b содержащим агрегируемые данные проходит существенно медленнее чем с предварительно ограниченным набором данных.

> А вот таки и есть разница.

Докажите. Не "левыми" картинками (они ничего не доказывают), а планами запросов.

> проходит существенно медленнее

Или не происходит (запрос неправильный, к примеру), или не медленнее (сравниваются совершенно разные вещи)...

В сторону: Вот зачем целый день рассказывать что-то туманное вместо того, чтобы за 5-10 минут показать конкретные планы?
Такое впечатление, что некоторые сюда приходят не за помощью, а за утешением. ;(

EXPLAIN не заходит в функции придется лезть в потраха но если вы там разберетесь..

заходит, auto_explain.log_nested_statements

Зато он покажет нам что-то реальное, как про view, так и про функцию.
Ну и да, https://t.me/pgsql/312920

А можете пояснить, зачем Вам потребовался array_agg для такого количества данных? Чем плоская таблица не устраивает? И если не сложно, покажите описание таблицы и вьюхи

Я писал агрегация для предствления данных уровня два свойтсва. сам набр не велик но связвыание в view занимвет больше времени чем через функцию. EXPALIN ANALYZE мне потраха вызова функции не показвает, но запрос я могу смотреть

Это же ваша картинка с плоской таблицей?

Вот это плохой ответ, если вопрос для вас так стоит, то пожалуй на этом закончим. И тем не менее спасибо за ваше время.

> Вот это плохой ответ

Это только Ваше мнение. Пока что Вы просто потратили тут немало времени, и никто [почти] ничего от этого не получил.

> то пожалуй на этом закончим.

Да, давно пора. Вам бы стоило научиться вопросы нормально задавать.
И да, если Вам виднее, нужна или нет уточняющая информация (которую у Вас просят те, кто в этом разбирается), то почему же Вы не можете решить свою проблему? ;)

Видимо ввожу в заблуждение отсутствием причины своего вопроса. Задача боевая, в наследство достался элементарный джоин, который выдаёт не то, что ожидается. Я представляю, как можно исправить не в один джоин, но вероятно это будет медленнее по производительности, чем один оптимизированый джоин.

Спасибо, пойду разбираться.

Спасибо, буду знать

Тогда что-то вроде:

WITH a(id) AS (
   VALUES (1), (2), (3), (4), (5), (6)
), b(id) AS (
   VALUES (1), (3), (5)
)
SELECT *
  FROM a
  LEFT JOIN LATERAL (
       SELECT MAX(b.id) AS max_b_id
         FROM b
        WHERE b.id <= a.id
      ) AS bm
   ON true;

будет лучше в большинстве ситуаций.