Re: User Defined Functions/AM's inherently slow? - Mailing list pgsql-hackers

From Eric Ridge
Subject Re: User Defined Functions/AM's inherently slow?
Date
Msg-id 83E5131E-496F-11D8-B3E7-000A95BB5944@tcdi.com
Whole thread Raw
In response to Re: User Defined Functions/AM's inherently slow?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Jan 17, 2004, at 11:27 PM, Tom Lane wrote:

> Eric Ridge <ebr@tcdi.com> writes:
>> costestimate: {
>>     PG_RETURN_VOID();
>> }
>
> This at least needs to set some values into the output parameters ---
> zeroes are okay, not setting them at all isn't.  I'm surprised the
> planner doesn't go nuts.  It looks from your EXPLAIN results like
> the values are coming up zero anyway, but seeing that cost_index()
> doesn't do anything to initialize those local variables, I'd expect
> fairly unpredictable behavior.

I have tried setting them all to zero, and even using the 
backend/utils/adt/selfuncs.c:genericcostestimate() code (it's not 
exported, it seems), but no matter what sane (or crazy!) numbers I 
provide for the cost estimate, the "fact" remains, my AM, which does 
"nothing" is slower than the builtin btree AM.

Could this just be related to the fact that my AM is in a .so, and 
there's just some operating system/C runtime overhead in calling 
functions in dynamically loaded libraries?

eric



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: User Defined Functions/AM's inherently slow?
Next
From: Eric Ridge
Date:
Subject: Re: User Defined Functions/AM's inherently slow?