User Defined Functions/AM's inherently slow?

From: Eric Ridge <ebr(at)tcdi(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: User Defined Functions/AM's inherently slow?
Date: 2004-01-18 02:25:43
Message-ID: 9DE6DA4C-495D-11D8-B3E7-000A95BB5944@tcdi.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I've created a stub AM that literally does nothing. It indexes
nothing. It scans for nothing. Nadda. It does just enough work to
specify return values that prevent PG from dumping core.

What I've found is that this stub AM, compiled with the same options as
postgres itself (-O2 -fno-strict-aliasing), is roughly 4 times slower
than the built in btree AM that actually does something useful!

The test table contains 1 column, and 1 row:

My stub AM:
explain analyze select * from test where a ==> '1';
Total runtime: 0.254 ms

builtin btree AM:
explain analyze select * from test where a = '1';
Total runtime: 0.058 ms

(I ran each one a number times, with basically the same results).

What gives? *scratches head* I know btree's are efficient, but geez,
can they really be more efficient than O(zero)? :) Looking at the
backtrace from the beginscan function of each AM, PG doesn't appear to
do anything different for user-provided AM's.

My platform is OS X 10.3.2, using PG 7.4, gcc version 3.3 (Apple's
build #1495).

Any insight would be greatly appreciated.

Thanks!

eric

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-01-18 03:18:36 Re: Bug in pg_autovacuum ?
Previous Message Cott Lang 2004-01-17 23:22:45 Bug in pg_autovacuum ?