Re: Slow planning time for custom function

Hi,

thanks for your help which already resolved the issue for me. I worked through your replies and it is indeed a startup delay for the first call to a plv8 function in a session. I pasted the query plans below for comparison.

```
explain analyze select normalizeunidiff('')

QUERY PLAN
-------------------------------------------------------------------------------------
Result (cost=0.00..0.01 rows=1 width=32) (actual time=0.002..0.002 rows=1 loops=1)
Planning time: 1863.782 ms
Execution time: 0.022 ms
```

Then I ran again multiple times, to make sure that there was not some kind of startup delay:
```
select normalizeunidiff('');
explain analyze select normalizeunidiff('');

QUERY PLAN
-------------------------------------------------------------------------------------
Result (cost=0.00..0.01 rows=1 width=32) (actual time=0.000..0.001 rows=1 loops=1)
Planning time: 0.190 ms
Execution time: 0.008 ms
```

Thanks again
-Ben

> On 24. Mar 2018, at 02:52, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>
> On 24 March 2018 at 14:35, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> How long does planning take if you repeat this? I wonder if a good chunk
>> of those 1.8s is initial loading of plv8.
>
> Maybe, but it also could be the execution of the function, after all,
> the planner does invoke immutable functions:
>
> # explain verbose select lower('TEST');
> QUERY PLAN
> -------------------------------------------
> Result (cost=0.00..0.01 rows=1 width=32)
> Output: 'test'::text
> (2 rows)
>
> Would be interesting to see what changes without the IMMUTABLE flag.
>
> --
> David Rowley http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services