Re: Why is indexonlyscan so darned slow?

On Sun, May 20, 2012 at 3:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Another possibility is to try to reduce the costs of index_getnext_tid
> and FunctionCall2Coll, which are basically just trampolines to reach
> btgettuple.  It's not immediately obvious how to make that much better
> though.

Hmm... this seems awfully similar to the problem we tried to solve
with the sortsupport infrastructure. Maybe something similar would be
warranted here, to save the overhead of repeated argument packing and
unpacking.

Here's some 'perf' results from the IBM POWER7 box:

10.01% postgres postgres [.] visibilitymap_test
8.78% postgres postgres [.] IndexOnlyNext
7.85% postgres postgres [.] btgettuple
5.67% postgres postgres [.] ExecProject
5.56% postgres postgres [.] ExecProcNode
5.51% postgres postgres [.] advance_transition_function
5.06% postgres postgres [.] advance_aggregates
5.02% postgres postgres [.] ExecScan
4.43% postgres postgres [.] FunctionCall2Coll
4.11% postgres postgres [.] _bt_checkkeys
3.54% postgres postgres [.] ExecClearTuple
3.42% postgres postgres [.] int8inc
3.25% postgres postgres [.] _bt_next
3.19% postgres postgres [.] MemoryContextReset
2.95% postgres postgres [.] index_getnext_tid
2.81% postgres postgres [.] _bt_readpage
2.43% postgres postgres [.] _bt_saveitem
2.42% postgres postgres [.] ExecIndexOnlyScan
2.32% postgres libc-2.14.90.so [.] memcpy

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company