Re: Optimze usage of immutable functions as relation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Optimze usage of immutable functions as relation
Date: 2019-08-01 22:57:16
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)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.

* 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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2019-08-01 22:57:45 Re: NOT IN subquery optimization
Previous Message Thomas Munro 2019-08-01 22:41:39 Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions?