|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>|
|Subject:||Re: Optimze usage of immutable functions as relation|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
> 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.
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
|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?|