pgsql: Allow functions-in-FROM to be pulled up if they reduce toconsta - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Allow functions-in-FROM to be pulled up if they reduce toconsta
Date
Msg-id E1htJu7-0002oG-Aj@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Allow functions-in-FROM to be pulled up if they reduce to constants.

This allows simplification of the plan tree in some common usage
patterns: we can get rid of a join to the function RTE.

In principle we could pull up any immutable expression, but restricting
it to Consts avoids the risk that multiple evaluations of the expression
might cost more than we can save.  (Possibly this could be improved in
future --- but we've more or less promised people that putting a function
in 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 to
inline_set_returning_functions(), which already has to iterate over
every function RTE, and in consequence renamed that function to
preprocess_function_rtes().  A useful consequence is that
inline_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 where
everything that needs pullup_replace_vars() processing is, so that
the new pull_up_constant_function() routine can share it.  We'd
gotten away with one-and-a-half copies of that code so far, since
pull_up_simple_values() could assume that a lot of cases didn't apply
to it --- but I don't think pull_up_constant_function() can make any
simplifying assumptions.  Might as well make pull_up_simple_values()
use it too.

(Possibly this refactoring should go further: maybe we could share
some 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 be
changed because inlining its function RTEs would destroy the point
of the test, namely to check join order.

Alexander Kuzmenkov and Aleksandr Parfenov, reviewed by
Antonin Houska and Anastasia Lubennikova, and whacked around
some more by me

Discussion: https://postgr.es/m/402356c32eeb93d4fed01f66d6c7fe2d@postgrespro.ru

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/7266d0997dd2a0632da38a594c78e25ff21df67e

Modified Files
--------------
src/backend/optimizer/plan/planner.c      |  17 +-
src/backend/optimizer/prep/prepjointree.c | 356 +++++++++++++++++++++---------
src/backend/optimizer/util/clauses.c      |  41 +---
src/include/optimizer/prep.h              |   2 +-
src/test/regress/expected/join.out        | 141 +++++++++++-
src/test/regress/expected/tsearch.out     |  22 ++
src/test/regress/sql/join.sql             |  65 +++++-
src/test/regress/sql/tsearch.sql          |  11 +
8 files changed, 499 insertions(+), 156 deletions(-)


pgsql-committers by date:

Previous
From: Peter Geoghegan
Date:
Subject: pgsql: Bump catversion.
Next
From: Jeff Davis
Date:
Subject: pgsql: Allow simplehash to use already-calculated hash values.