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