Re: Overhead for stats_command_string et al, take 2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Overhead for stats_command_string et al, take 2
Date
Msg-id 11069.1150906797@sss.pgh.pa.us
Whole thread Raw
In response to Overhead for stats_command_string et al, take 2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> BTW, according to "top" the CPU usage percentages in these tests are
> on the order of 55% backend, 45% psql.  Methinks psql needs a round
> of performance tuning ...

oprofile tells the tale:

CPU: P4 / Xeon with 2 hyper-threads, speed 2793.03 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped)
with a unit mask of 0x01 (mandatory) count 240000
GLOBAL_POWER_E...| samples|      %|
------------------  682534 52.7683 /usr/lib/debug/lib/modules/2.6.16-1.2133_FC5/vmlinux  274747 21.2413
/home/tgl/testversion/bin/postgres 226306 17.4962 /lib64/libc-2.4.so   54296  4.1977 /home/tgl/testversion/bin/psql
45376 3.5081 /home/tgl/testversion/lib/libpq.so.5.0    5302  0.4099 /usr/bin/oprofiled    1954  0.1511 /oprofile
 

It's all about the kernel process-switch overhead, which is being blamed
equally on both processes.

I did find some low-hanging fruit in GetVariable(), but nothing else
that looked readily improvable.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Dave Page"
Date:
Subject: Re: CVS HEAD busted on Windows?
Next
From: Alvaro Herrera
Date:
Subject: UTF8 server-side on Win32?