Re: [pgsql-hackers-win32] Help with tuning this query (with

> -----Original Message-----
> From: Greg Stark [mailto:[email protected]]
> Sent: Monday, March 07, 2005 5:15 PM
> To: Dave Held
> Cc: Greg Stark; John A Meinel; Tom Lane; Magnus Hagander; Ken 
> Egervari;
> [email protected]; [email protected]
> Subject: Re: [pgsql-hackers-win32] [PERFORM] Help with tuning 
> this query
> (with
> 
> "Dave Held" <[email protected]> writes:
> 
> > > 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?)
> > 
> > I believe QueryPerformanceCounter() already does this.
> [...]
> Already does what? 
> 
> Use rtdsc?

Yes.

> In which case using it would be a mistake. Since rtdsc doesn't
> work across processors.

It doesn't always use RDTSC.  I can't find anything authoritative on
when it does.  I would assume that it would use RDTSC when available
and something else otherwise.

> And using it via QueryPerformanceCounter would be a non-portable
> approach to using rtdsc. Much better to devise a portable
> approach that works on any architecture where something equivalent
> is available.

How do you know that QueryPerformanceCounter doesn't use RDTSC
where available, and something appropriate otherwise?  I don't see
how any strategy that explicitly executes RDTSC can be called 
"portable".

> Or already works on multi-processor machines? In which case, uh, ok.

According to MSDN it does work on MP systems, and they say that "it
doesn't matter which CPU gets called".

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East,  Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match