Re: pg_stat_lwlocks view - lwlocks statistics, round 2
От | Ants Aasma |
---|---|
Тема | Re: pg_stat_lwlocks view - lwlocks statistics, round 2 |
Дата | |
Msg-id | CA+CSw_v+-n0OxRvvN+gGTAFSKdMqTUOpvAnRnHVTohEig0AABw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_stat_lwlocks view - lwlocks statistics, round 2 (Robert Haas <robertmhaas@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: