From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | John A Meinel <john(at)arbash-meinel(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-07 18:05:30 |
Message-ID: | 874qfnbac5.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 pgsql-performance |
John A Meinel <john(at)arbash-meinel(dot)com> writes:
> Then we would only be wrong for 256 gettimeofday calls. I agree it isn't
> great, though. And probably better to just abstract (possibly just with
> #ifdef) the calls for accurate timing, from the calls that actually need
> the real time.
What would be really neato would be to use the rtdsc (sp?) or equivalent
assembly instruction where available. Most processors provide such a thing and
it would give much lower overhead and much more accurate answers.
The main problem I see with this would be on multi-processor machines.
(QueryPerformanceCounter does work properly on multi-processor machines,
right?)
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Held | 2005-03-07 22:30:40 | Re: [PERFORM] Help with tuning this query (with |
Previous Message | John A Meinel | 2005-03-07 17:24:07 | Re: [PERFORM] Help with tuning this query (with |
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Palmblad | 2005-03-07 22:26:04 | Re: Building postmaster with Profiling Support WAS "Tweaking a C |
Previous Message | Tom Lane | 2005-03-07 18:02:07 | Re: Help trying to tune query that executes 40x slower than in SqlServer |