Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit7266d09

Browse files
committed
Allow functions-in-FROM to be pulled up if they reduce to constants.
This allows simplification of the plan tree in some common usagepatterns: we can get rid of a join to the function RTE.In principle we could pull up any immutable expression, but restrictingit to Consts avoids the risk that multiple evaluations of the expressionmight cost more than we can save. (Possibly this could be improved infuture --- but we've more or less promised people that putting a functionin FROM guarantees single evaluation, so we'd have to tread carefully.)To do this, we need to rearrange when eval_const_expressions()happens for expressions in function RTEs. I moved it toinline_set_returning_functions(), which already has to iterate overevery function RTE, and in consequence renamed that function topreprocess_function_rtes(). A useful consequence is thatinline_set_returning_function() no longer has to do this for itself,simplifying that code.In passing, break out pull_up_simple_subquery's code that knows whereeverything that needs pullup_replace_vars() processing is, so thatthe new pull_up_constant_function() routine can share it. We'dgotten away with one-and-a-half copies of that code so far, sincepull_up_simple_values() could assume that a lot of cases didn't applyto it --- but I don't think pull_up_constant_function() can make anysimplifying assumptions. Might as well make pull_up_simple_values()use it too.(Possibly this refactoring should go further: maybe we could sharesome of the code to fill in the pullup_replace_vars_context struct?For now, I left it that the callers fill that completely.)Note: the one existing test case that this patch changes has to bechanged because inlining its function RTEs would destroy the pointof the test, namely to check join order.Alexander Kuzmenkov and Aleksandr Parfenov, reviewed byAntonin Houska and Anastasia Lubennikova, and whacked aroundsome more by meDiscussion:https://postgr.es/m/402356c32eeb93d4fed01f66d6c7fe2d@postgrespro.ru
1 parenta8d6a95 commit7266d09

File tree

8 files changed

+499
-156
lines changed

8 files changed

+499
-156
lines changed

‎src/backend/optimizer/plan/planner.c

Lines changed: 11 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -659,11 +659,12 @@ subquery_planner(PlannerGlobal *glob, Query *parse,
659659
pull_up_sublinks(root);
660660

661661
/*
662-
* Scan the rangetable for set-returning functions, and inline them if
663-
* possible (producing subqueries that might get pulled up next).
664-
* Recursion issues here are handled in the same way as for SubLinks.
662+
* Scan the rangetable for function RTEs, do const-simplification on them,
663+
* and then inline them if possible (producing subqueries that might get
664+
* pulled up next). Recursion issues here are handled in the same way as
665+
* for SubLinks.
665666
*/
666-
inline_set_returning_functions(root);
667+
preprocess_function_rtes(root);
667668

668669
/*
669670
* Check to see if any subqueries in the jointree can be merged into this
@@ -1071,7 +1072,9 @@ preprocess_expression(PlannerInfo *root, Node *expr, int kind)
10711072
expr=flatten_join_alias_vars(root->parse,expr);
10721073

10731074
/*
1074-
* Simplify constant expressions.
1075+
* Simplify constant expressions. For function RTEs, this was already
1076+
* done by preprocess_function_rtes ... but we have to do it again if the
1077+
* RTE is LATERAL and might have contained join alias variables.
10751078
*
10761079
* Note: an essential effect of this is to convert named-argument function
10771080
* calls to positional notation and insert the current actual values of
@@ -1085,7 +1088,9 @@ preprocess_expression(PlannerInfo *root, Node *expr, int kind)
10851088
* careful to maintain AND/OR flatness --- that is, do not generate a tree
10861089
* with AND directly under AND, nor OR directly under OR.
10871090
*/
1088-
expr=eval_const_expressions(root,expr);
1091+
if (!(kind==EXPRKIND_RTFUNC||
1092+
(kind==EXPRKIND_RTFUNC_LATERAL&& !root->hasJoinRTEs)))
1093+
expr=eval_const_expressions(root,expr);
10891094

10901095
/*
10911096
* If it's a qual or havingQual, canonicalize it.

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp