Re: User Defined Functions/AM's inherently slow?

From: Eric Ridge <ebr(at)tcdi(dot)com>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: User Defined Functions/AM's inherently slow?
Date: 2004-01-18 06:49:27
Message-ID: 759F1168-4982-11D8-B3E7-000A95BB5944@tcdi.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jan 18, 2004, at 1:34 AM, Christopher Kings-Lynne wrote:

>>> Theory B would be that there's some huge overhead in calling
>>> non-built-in
>>> functions on your platform. We do know that looking up a "C"
>>> function is
>>> significantly more expensive than looking up a "builtin" function,
>>> but
>>> there should only be half a dozen such calls involved in this test
>>> case;
>>> it's hard to credit that that takes 200 msec. Does the time drop at
>>> all
>>> on second and subsequent repetitions in a single backend run?
>> Yes, it drops from about .680ms to the .250ish that I posted.
>> I suppose I should try compiling this little stub into postgres, eh?
>
> What if you try the new preload_libraries (or whatever it's called)
> config variable in postgresql.conf in the 7.4 release?

yes, that takes care of the initial load time of the library itself
(bringing the initial .680ms back to .250ish for the first run), but
this is not the problem.

eric

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2004-01-18 21:52:38 Re: feature request... case sensitivity without double quotes
Previous Message Christopher Kings-Lynne 2004-01-18 06:34:00 Re: User Defined Functions/AM's inherently slow?