Re: GiST index performance

От: Adam Gundy
Тема: Re: GiST index performance
Дата: ,
Msg-id: 4A32722F.5070103@starsilk.net
(см: обсуждение, исходный текст)
Ответ на: Re: GiST index performance  (Matthew Wakeling)
Список: pgsql-performance

Скрыть дерево обсуждения

GiST index performance  (Matthew Wakeling, )
 Re: GiST index performance  (Robert Haas, )
  Re: GiST index performance  (Matthew Wakeling, )
   Re: GiST index performance  (Tom Lane, )
    Re: GiST index performance  (Matthew Wakeling, )
     Re: GiST index performance  (Tom Lane, )
      Re: GiST index performance  (Matthew Wakeling, )
       Re: GiST index performance  (Tom Lane, )
        Re: GiST index performance  (Matthew Wakeling, )
         Re: GiST index performance  (Matthew Wakeling, )
          Re: GiST index performance  (Matthew Wakeling, )
           Re: GiST index performance  (Tom Lane, )
           Re: GiST index performance  (Adam Gundy, )
        Re: GiST index performance  (Heikki Linnakangas, )
      Re: GiST index performance  (Greg Smith, )
       Re: GiST index performance  (Robert Haas, )
 Re: GiST index performance  (Bruce Momjian, )
  Re: GiST index performance  (Robert Haas, )
  Re: GiST index performance  (Matthew Wakeling, )
   Re: GiST index performance  (Robert Haas, )
   Re: GiST index performance  (Yeb Havinga, )
    Re: GiST index performance  (Yeb Havinga, )
     Re: GiST index performance  (Yeb Havinga, )
      Re: GiST index performance  (Yeb Havinga, )
       Re: GiST index performance  (Yeb Havinga, )
        Re: GiST index performance  (Kenneth Marshall, )
         Re: GiST index performance  (Yeb Havinga, )
          Re: GiST index performance  (Matthew Wakeling, )
           Re: GiST index performance  (Yeb Havinga, )
            Re: GiST index performance  (Matthew Wakeling, )

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

Вложения

В списке pgsql-performance по дате сообщения:

От: Rauan Maemirov
Дата:
Сообщение: Re: what server stats to track / monitor ?
От: Joshua Tolley
Дата:
Сообщение: Re: what server stats to track / monitor ?