Re: [pgsql-hackers-win32] Help with tuning this query (with
От | PFC |
---|---|
Тема | Re: [pgsql-hackers-win32] Help with tuning this query (with |
Дата | |
Msg-id | op.snavoht6th1vuj@localhost обсуждение исходный текст |
Ответ на | Re: [pgsql-hackers-win32] Help with tuning this query (with ("Steinar H. Gunderson" <sgunderson@bigfoot.com>) |
Список | pgsql-performance |
From the Linux Kernel (make menuconfig) there seem to be two new reliable sources for timing information. Note the remark about "Time Stamp Counter" below. Question is, which one of these (or others) are your API functions using ? I have absolutely no idea ! CONFIG_HPET_TIMER: This enables the use of the HPET for the kernel's internal timer. HPET is the next generation timer replacing legacy 8254s. You can safely choose Y here. However, HPET will only be activated if the platform and the BIOS support this feature. Otherwise the 8254 will be used for timing services. Choose N to continue using the legacy 8254 timer. Symbol: HPET_TIMER [=y] Prompt: HPET Timer Support Defined at arch/i386/Kconfig:440 Location: -> Processor type and features CONFIG_X86_PM_TIMER: The Power Management Timer is available on all ACPI-capable, in most cases even if ACPI is unusable or blacklisted. This timing source is not affected by powermanagement features like aggressive processor idling, throttling, frequency and/or voltage scaling, unlike the commonly used Time Stamp Counter (TSC) timing source. So, if you see messages like 'Losing too many ticks!' in the kernel logs, and/or you are using this on a notebook which does not yet have an HPET, you should say "Y" here. Symbol: X86_PM_TIMER [=y] Prompt: Power Management Timer Support Defined at drivers/acpi/Kconfig:319 Depends on: !X86_VOYAGER && !X86_VISWS && !IA64_HP_SIM && (IA64 || X86) && X86 && ACPI && ACPI_ Location: -> Power management options (ACPI, APM) -> ACPI (Advanced Configuration and Power Interface) Support -> ACPI Support (ACPI [=y]) On Tue, 08 Mar 2005 03:06:24 +0100, Steinar H. Gunderson <sgunderson@bigfoot.com> wrote: > On Mon, Mar 07, 2005 at 09:02:38PM -0500, Tom Lane wrote: >> One thought that was bothering me was that if the CPU goes idle while >> waiting for disk I/O, its clock might stop or slow down dramatically. >> If we believed such a counter for EXPLAIN, we'd severely understate >> the cost of disk I/O. >> >> I dunno if that is the case on any Windows hardware or not, but none >> of this thread is making me feel confident that we know what >> QueryPerformanceCounter does measure. > > I believe the counter is actually good in such a situation -- I'm not a > Win32 > guru, but I believe it is by far the best timer for measuring, well, > performance of a process like this. After all, it's what it was designed > to > be :-) > > OBTW, I think I can name something like 15 or 20 different function > calls to > measure time in the Win32 API (all of them in use); it really is a giant > mess. > > /* Steinar */
В списке pgsql-performance по дате отправления: