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

From: Eric Ridge <ebr(at)tcdi(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: User Defined Functions/AM's inherently slow?
Date: 2004-01-18 04:33:51
Message-ID: 83E5131E-496F-11D8-B3E7-000A95BB5944@tcdi.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jan 17, 2004, at 11:27 PM, Tom Lane wrote:

> Eric Ridge <ebr(at)tcdi(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Eric Ridge 2004-01-18 04:46:32 Re: User Defined Functions/AM's inherently slow?
Previous Message Tom Lane 2004-01-18 04:33:20 Re: User Defined Functions/AM's inherently slow?