Re: [HACKERS] loading libraries on Postmaster startup

Joe Conway wrote:
> Tom Lane wrote:
>> Joe Conway <mail(at)joeconway(dot)com> writes:
>>> In my testing with PL/R, it reduces the first call to a PL/R function
>>> (after connecting) from almost 2 seconds, down to about 8 ms.
>>
>> Hm, pretty significant. Can you measure any per-fork cost (ie, the loss
>> incurred by children that don't use PL/R)? Is there any measurable
>> benefit for our other PLs (plperl etc)?
>
> Here's what I got:
>
> 10000 connect/disconnect in tight loop
> ----------------------------------------------------------
> condition time top
> ----------------------------------------------------------
> with no preload 87 seconds ~10% CPU, ~2.2 MB
> with plr preload 133 seconds ~10% CPU, ~13 MB
> with plperl preload 92 seconds ~10% CPU, ~3.2 MB
> with pltcl preload 88 seconds ~10% CPU, ~2.3 MB
> with plpython preload 93 seconds ~10% CPU, ~2.3 MB
>
>
> 1000 connect/"select some_simple_func()"/disconnect in tight loop
> ------------------------------------------------------------------
> condition time top
> ------------------------------------------------------------------
> plr-func without preload 739 seconds ~60% CPU, ~13 MB
> plr-func with preload 26 seconds ~10% CPU, ~13 MB
> plperl-func without preload 46 seconds ~4% CPU, ~3.2 MB
> plperl-func with preload 33 seconds ~3% CPU, ~3.2 MB
> pltcl-func without preload 22 seconds ~5% CPU, ~2.3 MB
> pltcl-func with preload 17 seconds ~4% CPU, ~2.3 MB
> plpython-func without preload 33 seconds ~4% CPU, ~2.3 MB
> plpython-func with preload 31 seconds ~4% CPU, ~2.3 MB
>

Here's an updated copy of the patch. The original patch was failing due
to code drift in cvs.

Peter's suggestion (__attribute__((constructor))) is interesting, but it
appears to be a gcc specific extension, and hence non-portable.

I'd still like to see this applied if there are no other objections.
From the above info it is apparent that the benefit outweighs the cost
for plperl and pltcl (although not as significantly as for plr).

Joe