Re: GiST index performance

From: Matthew Wakeling
Subject: Re: GiST index performance
Date: ,
Msg-id: alpine.DEB.2.00.0906111810480.4337@aragorn.flymine.org
(view: Whole thread, Raw)
In response to: Re: GiST index performance  (Matthew Wakeling)
Responses: Re: GiST index performance  (Tom Lane)
Re: GiST index performance  (Adam Gundy)
List: pgsql-performance

Tree view

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, )

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.


pgsql-performance by date:

From: Erik Aronesty
Date:
Subject: Re: Best way to load test a postgresql server
From: Shaul Dar
Date:
Subject: Re: Postgres replication: dump/restore, PITR, Slony,...?