From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: GiST index performance |
Date: | 2009-06-11 13:27:36 |
Message-ID: | 4935.1244726856@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Matthew Wakeling <matthew(at)flymine(dot)org> writes:
> That sucks. However, as another observation, no calls to "gistfindnext"
> are recorded in the profile either, and that's in the same source file as
> "gistnext" which is recorded. Could it have been inlined?
Probably.
> Shouldn't inlining be switched off on a profiling build?
Why? You generally want to profile the code's actual behavior, or as
near as you can get to observing that. Defeating compiler optimizations
doesn't sound like something that -pg should do on its own. If you
really want it, there's a switch for it.
> Oprofile scares me with the sheer number of options.
You can ignore practically all of them; the defaults are pretty sane.
The recipe I usually follow is:
Initial setup (only needed once per system boot):
sudo opcontrol --init
sudo opcontrol --setup --no-vmlinux
(If you need detail about what the kernel is doing, you need kernel
debug symbols and then specify them on the previous line)
Start/stop profiling
sudo opcontrol --start
sudo opcontrol --reset
... exercise your debug-enabled program here ...
sudo opcontrol --dump ; sudo opcontrol --shutdown
The test case should run at least a minute or two to get numbers with
reasonable accuracy.
Analysis:
opreport --long-filenames | more
opreport -l image:/path/to/postgres | more
if you really want detail:
opannotate --source /path/to/postgres >someplace
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2009-06-11 14:33:04 | Re: Postgres replication: dump/restore, PITR, Slony,...? |
Previous Message | Shaul Dar | 2009-06-11 13:12:32 | Postgres replication: dump/restore, PITR, Slony,...? |