Re: GiST index performance
От | Tom Lane |
---|---|
Тема | Re: GiST index performance |
Дата | |
Msg-id | 4935.1244726856@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: GiST index performance (Matthew Wakeling <matthew@flymine.org>) |
Ответы |
Re: GiST index performance
Re: GiST index performance |
Список | pgsql-performance |
Matthew Wakeling <matthew@flymine.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
В списке pgsql-performance по дате отправления: