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

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>
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 02:02:38
Message-ID: 1971.1110247358@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers-win32pgsql-performance
"Steinar H. Gunderson" <sgunderson(at)bigfoot(dot)com> writes:
> RDTSC is a bad source of information for this kind of thing, as the CPU
> frequency might vary.

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.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Steinar H. GundersonDate: 2005-03-08 02:06:24
Subject: Re: [PERFORM] Help with tuning this query (with
Previous:From: Steinar H. GundersonDate: 2005-03-08 01:37:50
Subject: Re: [PERFORM] Help with tuning this query (with

pgsql-hackers-win32 by date

Next:From: Steinar H. GundersonDate: 2005-03-08 02:06:24
Subject: Re: [PERFORM] Help with tuning this query (with
Previous:From: Steinar H. GundersonDate: 2005-03-08 01:37:50
Subject: Re: [PERFORM] Help with tuning this query (with

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