From: Dimitri Fontaine <dim@dalibo.com>
Organization: dalibo
To: pgsql-hackers@postgresql.org,
	Martijn van Oosterhout <kleptog@svana.org>
Subject: Re: [HACKERS] EXPLAIN ANALYZE on 8.2
Date: Fri, 15 Dec 2006 12:24:35 +0100
User-Agent: KMail/1.9.5
Cc: Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Kelly Burkhart <kelly.burkhart@gmail.com>,
	Evgeny Gridasov <eugrid@fpm.kubsu.ru>, pgsql-performance@postgresql.org
References: <20061214163230.d46f0138.eugrid@fpm.kubsu.ru>
	<1166178488.3882.56.camel@silverbirch.site>
	<20061215105008.GD958@svana.org>
In-Reply-To: <20061215105008.GD958@svana.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1875586.H5LF1B9zun";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200612151224.42158.dim@dalibo.com>

--nextPart1875586.H5LF1B9zun
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi list,

Le vendredi 15 d=E9cembre 2006 11:50, Martijn van Oosterhout a =E9crit=A0:
> BTW, doing gettimeofday() without kernel entry is not really possible.
> You could use the cycle counter but it has the problem that if you have
> multiple CPUs you need to calibrate the result. If the CPU goes to
> sleep, there's is no way for the userspace process to know. Only the
> kernel has all the relevent information about what "time" is to get a
> reasonable result.

I remember having played with intel RDTSC (time stamp counter) for some tim=
ing=20
measurement, but just read from several sources (including linux kernel=20
hackers considering its usage for gettimeofday()  implementation) that TSC =
is=20
not an accurate method to have elapsed time information.

May be some others method than gettimeofday() are available (Lamport=20
Timestamps, as PGDG may have to consider having a distributed processing=20
ready EA in some future), cheaper and accurate?
After all, the discussion, as far as I understand it, is about having a=20
accurate measure of duration of events, knowing when they occurred in the d=
ay=20
does not seem to be the point.

My 2=A2, hoping this could be somehow helpfull,
=2D-=20
Dimitri Fontaine
http://www.dalibo.com/

--nextPart1875586.H5LF1B9zun
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBFgoX6l4JX7QVNfwQRAsZJAJ9OvzBumiXFdd9uP5HkuSe2n/fogwCfXpdd
zf1K+3pe7dYnbvZdkJ4hrUw=
=qK/Z
-----END PGP SIGNATURE-----

--nextPart1875586.H5LF1B9zun--