Re: pg_stat_lwlocks view - lwlocks statistics, round 2
Ants Aasma <ants@cybertec.at>
From: Ants Aasma <ants@cybertec.at>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Satoshi Nagayasu <snaga@uptime.jp>, Jeff Janes <jeff.janes@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Fujii Masao <masao.fujii@gmail.com>, Michael Paquier <michael.paquier@gmail.com>, pgsql-hackers@postgresql.org, Qi Huang <huangqiyx@hotmail.com>, Josh Berkus <josh@agliodbs.com>
Date: 2012-10-19T00:37:07Z
Lists: pgsql-hackers
On Thu, Oct 18, 2012 at 10:36 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Sadly, the situation on Windows doesn't look so good. I > don't remember the exact numbers but I think it was something like 40 > or 60 or 80 times slower on the Windows box one of my colleagues > tested than it is on Linux. Do you happen to know the hardware and Windows version? Windows QueryPerformanceCounter that instr_time.h uses should use RDTSC based timing when the hardware can support it, just like Linux. I don't know if Windows can avoid syscall overhead though. > Maybe it's worth finding a platform where > pg_test_timing reports that timing is very slow and then measuring how > much impact this has on something like a pgbench or pgbench -S > workload. This can easily be tested on Linux by changing to the hpet or acpi_pm clocksource. There probably still are platforms that can do worse than this, but probably not by orders of magnitude. Regards, Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de