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 03:45:37 |
Message-ID: | C7596014-4968-11D8-B3E7-000A95BB5944@tcdi.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jan 17, 2004, at 10:22 PM, Tom Lane wrote:
> Eric Ridge <ebr(at)tcdi(dot)com> writes:
>> I've created a stub AM that literally does nothing.
>
> It's not possible for an index AM to "do nothing", at least not for an
> indexscan. It has to return tuple pointers. What are you doing for
> that?
costestimate: {
PG_RETURN_VOID();
}
beginscan: {
Relation index = (Relation) PG_GETARG_POINTER(0);
int keysz = PG_GETARG_INT32(1);
ScanKey scankey = (ScanKey) PG_GETARG_POINTER(2);
IndexScanDesc scan = RelationGetIndexScan(index, keysz, scankey);
PG_RETURN_POINTER(scan);
}
rescan: {
PG_RETURN_VOID();
}
gettuple: {
PG_RETURN_BOOL(false);
}
endscan: {
PG_RETURN_VOID();
}
I think the above is about as close to "nothing" as one can get.
In trying to track down some performance issues with my real AM, I
decided to make this stub AM just to see what the overhead is... then I
started seeing these crazy results.
eric
From | Date | Subject | |
---|---|---|---|
Next Message | Eric Ridge | 2004-01-18 04:06:31 | Re: User Defined Functions/AM's inherently slow? |
Previous Message | Tom Lane | 2004-01-18 03:22:51 | Re: User Defined Functions/AM's inherently slow? |