Много разговоров шло о выпуска версии 13 об упреждающей выборке.

Question

Много разговоров шло о выпуска версии 13 об упреждающей выборке.

Я не утверждаю что понял верно смысл реализации данной концепции но у меня сложилось мнение что зерно данного решения состоит в предварительном расчете полей непосредственно участвующих в связывании JOIN, условиях WHERE и блоках фильтрации. Возможно я не прав, в любом случае данные новшества в итоге не попали в 13 версию. И вообще ветка данная как то заглохла. Может кто то более компетентный в курсе что то делается в этом направлении? Поясню зачем? Для тех кому не лезут в голову многоэтажные JOIN разделить на view можно но всегда есть НО в отсутствие функций принимающих кортежи разбиение на VIEW при JOIN без упреждающей выборки существенно снижает производительность. Я обошел данное ограничение воспользовавшись массивами выборки через функции ANY в принимающих функциях получив хорошие результаты в итоговых выражениях, что вызывает другой вопрос, Как это отразится на глубине выборки, насколько массивы отличаются от списка кортежей. в перспективе до 10 тысяч записей я не вижу проблем. Но люди тут показывают такие базы которых я не видел с 1998 года 🙈, не думаю что мой движок в принципе применим для таких решений но хотелось бы понять при использовании массивов я упрусь в их размер относительно списка кортежей или в плане реализации это все таки родственные сущности?

#backend #devops #pgsql #programming #russian

0

27.06.2021

7 ответов

25 просмотров

Дмитрий Иванов Автор вопроса

Для примера приведу один из вариантов функции ограничения выборки которые я использую : CREATE OR REPLACE FUNCTION bpd.int_object_ext_prop_by_id_object_array(object_array bigint[]) RETURNS SETOF bpd.int_object_ext LANGUAGE plpgsql STABLE PARALLEL SAFE AS $function$ DECLARE BEGIN RETURN QUERY SELECT op.id_object_carrier AS id, array_agg((op.*)::bpd.cobject_prop) AS property_list FROM bpd.vobject_prop op WHERE (op.id_object_carrier = ANY(object_array)) GROUP BY op.id_object_carrier; END; $function$; -- -------------------------------------------------------------

0

27.06.2021

Дмитрий Иванов Автор вопроса

Yaroslav Schekin
Подождите... о чём конкретно речь (а то как-то тум...

Я поищу но речь идет о частичном расчете rows при первичном связывании таблиц во всяком случае я так это понял.

0

27.06.2021

Alex Yu

Дмитрий Иванов
Для примера приведу один из вариантов функции огра...

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

0

27.06.2021

Yaroslav Schekin

Зависит от запросов в них. Почти всегда лучше использовать inlinable SQL functions, а для чего-то "сложного" — plpgsql.

0

27.06.2021

Alex Yu

Я вижу в функции единственную инструкцию RETURN QUERY SELECT. plpgsql - выполняет роль glue language для SQL, но в функции из одной инструкции - "клей" не нужен. Вероятнее всего plpgsql-версия будет НЕ хуже, чем просто SQL. Впрочем, измеряйте все, не верьте утверждениям, но я не вижу обоснований для использования plpgsql в случаях, подобных Вашему

0

27.06.2021

Дмитрий Иванов Автор вопроса

Alex Yu
Я вижу в функции единственную инструкцию RETURN QU...

Массивы ест в sql?

0

27.06.2021

Yaroslav Schekin · Accepted Answer

Yaroslav Schekin

Подождите... о чём конкретно речь (а то как-то туманно)? Есть ссылки на threads в -hackers, или на commitfest?

0

27.06.2021

172 похожих чатов

Много разговоров шло о выпуска версии 13 об упреждающей выборке.

7 ответов

Похожие вопросы