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