Re: User Defined Functions/AM's inherently slow? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: User Defined Functions/AM's inherently slow?
Date
Msg-id 20129.1074484755@sss.pgh.pa.us
Whole thread Raw
In response to Re: User Defined Functions/AM's inherently slow?  (Eric B.Ridge <ebr@tcdi.com>)
List pgsql-hackers
"Eric B. Ridge" <ebr@tcdi.com> writes:
> Wow, thanks for spending the time on this.  What about for gettuple?  
> Do calls to it take advantage of the cache?  If not, this likely 
> explains some of my custom am's performance troubles.

gettuple is looked up once at the start of a scan, so there's no
per-tuple overhead involved there.  As I said before, we're usually
pretty good about avoiding per-tuple overheads --- the cost you
identified here is a per-query overhead.

> If there's anything I can do to help, let me know.  I'll be happy to 
> test any patches you might come up with too.

I have committed a patch into CVS HEAD --- give it a try.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Eric B.Ridge
Date:
Subject: Re: User Defined Functions/AM's inherently slow?
Next
From: tim@keow.org
Date:
Subject: [patch] jdbc build fix when ./configure is run in separate dir