Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] Help with tuning this query (with

From: PFC <lists(at)boutiquenumerique(dot)com>
To: "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Dave Held" <dave(dot)held(at)arrayservicesgrp(dot)com>,"Greg Stark" <gsstark(at)mit(dot)edu>,"John A Meinel" <john(at)arbash-meinel(dot)com>,"Magnus Hagander" <mha(at)sollentuna(dot)net>,"Ken Egervari" <ken(at)upfactor(dot)com>, pgsql-performance(at)postgresql(dot)org,pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: [PERFORM] Help with tuning this query (with
Date: 2005-03-08 03:51:43
Message-ID: op.snavoht6th1vuj@localhost (view raw or flat)
Thread:
Lists: pgsql-hackers-win32pgsql-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(at)bigfoot(dot)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 */



In response to

pgsql-performance by date

Next:From: John A MeinelDate: 2005-03-08 04:35:09
Subject: Re: [PERFORM] Help with tuning this query (with
Previous:From: Steinar H. GundersonDate: 2005-03-08 02:06:24
Subject: Re: [PERFORM] Help with tuning this query (with

pgsql-hackers-win32 by date

Next:From: John A MeinelDate: 2005-03-08 04:35:09
Subject: Re: [PERFORM] Help with tuning this query (with
Previous:From: Steinar H. GundersonDate: 2005-03-08 02:06:24
Subject: Re: [PERFORM] Help with tuning this query (with

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group