Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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:

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

In response to

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group