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
delayfor 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.rowley@2ndquadrant.com> wrote:
>
> On 24 March 2018 at 14:35, Andres Freund <andres@anarazel.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