Re: User Defined Functions/AM's inherently slow?
От | Eric Ridge |
---|---|
Тема | Re: User Defined Functions/AM's inherently slow? |
Дата | |
Msg-id | C7596014-4968-11D8-B3E7-000A95BB5944@tcdi.com обсуждение исходный текст |
Ответ на | Re: User Defined Functions/AM's inherently slow? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: User Defined Functions/AM's inherently slow?
|
Список | pgsql-hackers |
On Jan 17, 2004, at 10:22 PM, Tom Lane wrote: > Eric Ridge <ebr@tcdi.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
В списке pgsql-hackers по дате отправления: