Re: Optimze usage of immutable functions as relation

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

26.07.2019 21:26, Tom Lane wrote:
> I took a quick look at this and I have a couple of gripes ---
> * The naming and documentation of transform_const_function_to_result
> seem pretty off-point to me. ISTM the real goal of that function is to
> pull up constant values from RTE_FUNCTION RTEs. Replacing the RTE
> with an RTE_RESULT is just a side-effect that's needed so that we
> don't generate a useless FunctionScan plan node. I'd probably call
> it pull_up_constant_function or something like that.
> * It would be useful for the commentary to point out that in principle we
> could pull up any immutable (or, probably, even just stable) expression;
> but we don't, (a) for fear of multiple evaluations of the result costing
> us more than we can save, and (b) because a primary goal is to let the
> constant participate in further const-folding, and of course that won't
> happen for a non-Const.
> * The test cases are really pretty bogus, because int4(1) or int4(0) are
> not function invocations at all. The parser thinks those are no-op type
> casts, and so what comes out of parse analysis is already just a plain
> Const. Thus, not one of these test cases is actually verifying that
> const-folding of an immutable function has happened before we try to
> pull up. While you could dodge the problem today by, say, writing
> int8(0) which isn't a no-op cast, I'd recommend staying away from
> typename() notation altogether. There's too much baggage there and too
> little certainty that you wrote a function call not something else.
> The existing test cases you changed, with int4(sin(1)) and so on,
> are better examples of something that has to actively be folded to
> a constant.

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.

Anastasia Lubennikova
Postgres Professional:
The Russian Postgres Company

Attachment Content-Type Size
v8-0001-Simplify-immutable-RTE_FUNCTION-to-RTE_RESULT.patch text/x-patch 17.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-08-01 17:55:22 Re: tableam vs. TOAST
Previous Message Andres Freund 2019-08-01 17:53:06 Re: tableam vs. TOAST