Я о том, что я вообще не понимаю, о чём речь, например.
Об этом https://commitfest.postgresql.org/32/2569/ ? Или вот об этом https://commitfest.postgresql.org/21/1648/ ? Или ещё о чём-то?

> тесты показывают экспоненциальный прирост производительности, что говорит о том что чем точнее запрос тем быстрее он обрабатывается.

Послушайте... делать такие выводы на таких основаниях — это просто смешно.
Хотите обсудить конкретные примеры — покажите сравнение запросов / планов и таблицы.

@MelissaJBolden: user has been CAS banned

Это я понял, я постараюсь найти ветку которая вызвала у меня этот вариант реализации, пока не могу.  Но вопрос в том что если я использую ANY для ARRAY  я упрусь в размер чисто технически или нет по отношению к варианту с использованием табличных выражений

Вы же ни одного варианта не показали, и ничего не объясняете, на самом деле. :(
Вот к чему была эта функция https://t.me/pgsql/312861 ?

Я же показал что функция выпоняет группировку группировку данных по таблице значительного размера

И это лучше / хуже чем что конкретно? Или же — как это используется далее?

Если я ограничиваю начальную группировку через массив элементов выборки я получаю существенную выгоду. Но если элементов выборки будет слишком много мой первичный массив не сломается? вот в чем вопрос

> Если я ограничиваю начальную группировку через массив элементов выборки я получаю существенную выгоду.

Выгоду по сравнению с чем, опять-таки?

> мой первичный массив не сломается?

Зависит от того, что такое "слишком много" и "сломается". ;(
У массива (как и у любого значения в PostgreSQL) есть максимальный размер (в отличие от таблицы, например). Об этом речь?
Что мешает Вам просто попробовать, кстати?

Мешает трудоемкость внесения начальных данных обусловленная безобразностью реалтзации осходного проекта о котором даже не хочется говорить в приличном бществе

В некоторых ситуациях таким же образом можно показывать противоположные результаты, просто выполняя запросы в обратном порядке. ;)
Вы планы покажите. Текстом, естественно. И, желательно, view и функцию.

Функцию к первичному вью я показал по сути я использую ANY к ARRAY  в ее теле и вопрос то в том что у нас есть ограничение на COUNT или нет

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

Хм
Вопрос: а зачем language plpgsq? Почему не SQL?

-- CREATE VIEW "vobject_prop" ----------------------------------
CREATE OR REPLACE VIEW "bpd"."vobject_prop" AS  SELECT
........
  FROM ((((((bpd.object o
    JOIN bpd.vclass_prop_snapshot cp ON (((cp.id_class = o.id_class) AND (cp.timestamp_class = o.timestamp_class))))
    LEFT JOIN bpd.object_prop_user_small_val sv ON (((sv.id_object = o.id) AND (sv.id_class_prop = cp.id) AND (sv.timestamp_class = cp.timestamp_class))))
    LEFT JOIN bpd.object_prop_user_big_val bv ON (((bv.id_object = o.id) AND (bv.id_class_prop = cp.id) AND (bv.timestamp_class = cp.timestamp_class))))
    LEFT JOIN bpd.object_prop_link_val lv ON (((lv.id_object = o.id) AND (lv.id_class_prop = cp.id) AND (lv.timestamp_class = cp.timestamp_class))))
    LEFT JOIN bpd.object_prop_enum_val ev ON (((ev.id_object = o.id) AND (ev.id_class_prop = cp.id) AND (ev.timestamp_class = cp.timestamp_class))))
    LEFT JOIN bpd.prop_enum_val pev ON ((pev.id = ev.id_prop_enum_val)));;

А разница в производительности?

Лично мне чем дальше, тем меньше становится понятно.

Вы задаёте очень туманные вопросы, и вместо того, что Вас просят показать, показываете какие-то отрывки того, что Вам хочется. Таким образом бесполезно / крайне непродуктивно что-то обсуждать, IMNSHO, так что я прекращу, пожалуй. :(