Re: GiST index performance

Okay, I don't know quite what's happening here. Tom, perhaps you could
advise. Running opannotate --source, I get this sort of stuff:

/*
* Total samples for file : ".../postgresql-8.4beta2/src/backend/access/gist/gistget.c"
*
* 6880 0.2680
*/

and then:

:static int64
:gistnext(IndexScanDesc scan, TIDBitmap *tbm)
81 0.0032 :{ /* gistnext total: 420087 16.3649 */
: Page p;

The gistnext total doesn't seem to correspond to the amount I get by
adding up all the individual lines in gistnest. Moreover, it is greater
than the total samples attributed to the whole file, and greater than the
samples assigned to all the lines where gistnext is called.

However, yes it does seem like fmgr.c accounts for a large proportion of
samples. Also, I still seem to be getting mcount, even after recompiling
without --enable-profiling.

CPU: Core 2, speed 1998 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
samples % image name app name symbol name
460213 17.9280 postgres postgres fmgr_oldstyle
420087 16.3649 postgres postgres gistnext
254975 9.9328 postgres postgres FunctionCall5
239572 9.3327 libc-2.9.so libc-2.9.so mcount
219963 8.5689 libc-2.9.so libc-2.9.so __mcount_internal
125674 4.8957 no-vmlinux no-vmlinux (no symbols)
117184 4.5650 postgres postgres gistdentryinit
106967 4.1670 btree_gist.so btree_gist.so gbt_int4_consistent
95677 3.7272 postgres postgres FunctionCall1
75397 2.9372 bioseg.so bioseg.so bioseg_gist_consistent
58832 2.2919 btree_gist.so btree_gist.so gbt_num_consistent
39128 1.5243 bioseg.so bioseg.so bioseg_overlap
33874 1.3196 libxul.so libxul.so (no symbols)
32008 1.2469 bioseg.so bioseg.so bioseg_gist_leaf_consistent
20890 0.8138 nvidia_drv.so nvidia_drv.so (no symbols)
19321 0.7527 bioseg.so bioseg.so bioseg_gist_decompress
17365 0.6765 libmozjs.so.1d libmozjs.so.1d (no symbols)

Matthew

--
A good programmer is one who looks both ways before crossing a one-way street.
Considering the quality and quantity of one-way streets in Cambridge, it
should be no surprise that there are so many good programmers there.