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

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

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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32pgsql-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,


In response to

pgsql-performance by date

Next:From: Adam PalmbladDate: 2005-03-07 22:26:04
Subject: Re: Building postmaster with Profiling Support WAS "Tweaking a C
Previous:From: Tom LaneDate: 2005-03-07 18:02:07
Subject: Re: Help trying to tune query that executes 40x slower than in SqlServer

pgsql-hackers-win32 by date

Next:From: Dave HeldDate: 2005-03-07 22:30:40
Subject: Re: [PERFORM] Help with tuning this query (with
Previous:From: John A MeinelDate: 2005-03-07 17:24:07
Subject: Re: [PERFORM] Help with tuning this query (with

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