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 |
Message-ID: | 24410.1564700236@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
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
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? |