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
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? |