Matthew Wakeling wrote:
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.
there's another alternative for profiling that you might try if you can't get sensible results out of oprofile - cachegrind (which is part of the valgrind toolset).
basically it runs the code in an emulated environment, but records every access (reads/writes/CPU cycles/cache hits/misses/etc). it's *extremely* good at finding hotspots, even when they are due to 'cache flushing' behavior in your code (for example, trawling a linked list is touching a bunch of pages and effectively blowing your CPU cache..)
there's an associated graphical tool called kcachegrind which takes the dumped output and lets you drill down, even to the source code level (with cycle count/percentage annotations on the source lines)
all you need to do is compile postgres with debug symbols (full optimization ON, otherwise you end up reaching the wrong conclusions).
there's an example of running valgrind on postgres here: http://blog.cleverelephant.ca/2008/08/valgrinding-postgis.htmlfor cachegrind, you basically need to use 'cachegrind' instead of 'valgrind', and don't disable optimization when you build..
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
