Re: Optimze usage of immutable functions as relation
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2019-08-01T22:57:16Z
Lists: pgsql-hackers
Anastasia Lubennikova <a.lubennikova@postgrespro.ru> writes:
> Thank you for pointing out on specific of int4() function,
> I updated tests to use dummy plpgsql function.
> I'm not sure if tests of various join types are redundant but I left them.
> As far as I understand, the principal motivation of this patch was to
> optimize
> function scan joins that occur in FTS queries. For example:
> select * from test_tsquery, to_tsquery('english', 'new') q where
> txtsample @@ q;
> So I also added another test to tsearch.sql to illustrate difference
> between optimized and not optimized plans.
Fair enough.
I've pushed this after a good deal of further hackery on the code.
Notably
* I had no faith that we still guaranteed to perform
eval_const_expressions on every function-RTE expression. Even if
that were true today, it'd be awfully easy to break in future,
if it only happened somewhere down in the recursion in
pull_up_subqueries_recurse. So I moved that responsibility to
an earlier spot that clearly traverses all function RTEs.
A happy side benefit is that inline_set_returning_function
gets simpler because it can assume that that already happened.
* It looked to me like the pullup_constant_function code wasn't
covering all the places where it might need to replace Vars
referencing the function RTE. I refactored things to avoid
having a bunch of code duplication while ensuring it hits
everyplace that pull_up_simple_subquery does.
regards, tom lane
Commits
-
Prevent bogus pullup of constant-valued functions returning composite.
- a9ae99d01909 13.0 landed
-
Allow functions-in-FROM to be pulled up if they reduce to constants.
- 7266d0997dd2 13.0 landed