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

In response to

Responses

Browse pgsql-hackers by date

  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?