Re: pg_test_timing tool for EXPLAIN ANALYZE overhead
От | Greg Smith |
---|---|
Тема | Re: pg_test_timing tool for EXPLAIN ANALYZE overhead |
Дата | |
Msg-id | 4F45279C.6080008@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: pg_test_timing tool for EXPLAIN ANALYZE overhead (Marti Raudsepp <marti@juffo.org>) |
Ответы |
Re: pg_test_timing tool for EXPLAIN ANALYZE overhead
|
Список | pgsql-hackers |
On 02/22/2012 12:25 PM, Marti Raudsepp wrote: > 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. From the patch: Newer operating systems may check for the known TSC problems and switch to a slower, more stable clock source when they are seen. If your system supports TSC time but doesn't default to that, it may be disabled for a good reason. I ran into a case like you're showing here in my longer exploration of this at http://archives.postgresql.org/message-id/4EDF1871.2010209@2ndQuadrant.com I stopped just short of showing what the TSCerror message looked like. I hoped that with the above and some examples showing dmesg | grep, that would be enough to lead enough people toward finding this on their own. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: