Re: pg_test_timing tool for EXPLAIN ANALYZE overhead

Поиск
Список
Период
Сортировка
От Marti Raudsepp
Тема Re: pg_test_timing tool for EXPLAIN ANALYZE overhead
Дата
Msg-id CABRT9RDAYnK87Z=pxaSEzYJPZhz95cKEOzZ6W22wYbH2pU5Rew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_test_timing tool for EXPLAIN ANALYZE overhead  (Greg Smith <greg@2ndQuadrant.com>)
Ответы Re: pg_test_timing tool for EXPLAIN ANALYZE overhead  (Greg Smith <greg@2ndQuadrant.com>)
Список pgsql-hackers
On Wed, Feb 22, 2012 at 18:44, Greg Smith <greg@2ndquadrant.com> wrote:
> As far as I've been able to tell, there aren't any issues unique to Windows
> there.  Multiple cores can have their TSC results get out of sync on Windows
> for the same reason they do on Linux systems, and there's also the same
> frequency/temperature issues.

Not on recent Linux kernel versions. Linux automatically detects when
the TSC is unstable (due to power management or out-of-sync
cores/sockets) and automatically falls back to the more expensive HPET
or ACPI methods.

e.g:
% dmesg |grep -i tsc
[    0.000000] Fast TSC calibration using PIT
[    0.164075] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
[    0.197062] Switching to clocksource tsc
[    0.260960] Marking TSC unstable due to TSC halts in idle

Whether these tests cover 100% of the possible conditions, and whether
the detection has race conditions or not, I don't know.

Regards,
Marti


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: foreign key locks, 2nd attempt
Следующее
От: Greg Smith
Дата:
Сообщение: Re: WIP: URI connection string support for libpq