Re: GiST index performance

From: Adam Gundy <adam(at)starsilk(dot)net>
To: Matthew Wakeling <matthew(at)flymine(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: GiST index performance
Date: 2009-06-12 15:20:15
Message-ID: 4A32722F.5070103@starsilk.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.html

for cachegrind, you basically need to use 'cachegrind' instead of
'valgrind', and don't disable optimization when you build..

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Sabino Mullane 2009-06-12 19:11:42 Re: Postgres replication: dump/restore, PITR, Slony,...?
Previous Message Shaul Dar 2009-06-12 11:27:10 Re: Postgres replication: dump/restore, PITR, Slony,...?