Received: from localhost (maia-3.hub.org [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 3B4849F9F08;
	Fri, 15 Dec 2006 06:50:39 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024)
	with ESMTP id 02468-01; Fri, 15 Dec 2006 06:50:24 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from svana.org (calyx.svana.org [125.62.87.134])
	by postgresql.org (Postfix) with ESMTP id 3BF1D9FA19B;
	Fri, 15 Dec 2006 06:50:27 -0400 (AST)
Received: from kleptog by svana.org with local (Exim 4.50)
	id 1GvAdk-0000d5-9e; Fri, 15 Dec 2006 21:50:08 +1100
Date: Fri, 15 Dec 2006 11:50:08 +0100
From: Martijn van Oosterhout <kleptog@svana.org>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Kelly Burkhart <kelly.burkhart@gmail.com>,
	Evgeny Gridasov <eugrid@fpm.kubsu.ru>,
	pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] EXPLAIN ANALYZE on 8.2
Message-ID: <20061215105008.GD958@svana.org>
Reply-To: Martijn van Oosterhout <kleptog@svana.org>
References: <20061214163230.d46f0138.eugrid@fpm.kubsu.ru>
	<21146.1166112702@sss.pgh.pa.us>
	<20061214192920.c75385d6.eugrid@fpm.kubsu.ru>
	<21516.1166114475@sss.pgh.pa.us>
	<fa1e4ce70612141543o8866d7fg417eca88ce9b1344@mail.gmail.com>
	<29450.1166141131@sss.pgh.pa.us>
	<1166178488.3882.56.camel@silverbirch.site>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="5gxpn/Q6ypwruk0T"
Content-Disposition: inline
In-Reply-To: <1166178488.3882.56.camel@silverbirch.site>
X-PGP-Key-ID: Length=1024; ID=0x0DC67BE6
X-PGP-Key-Fingerprint: 295F A899 A81A 156D B522  48A7 6394 F08A 0DC6 7BE6
X-PGP-Key-URL: <http://svana.org/kleptog/0DC67BE6.pgp.asc>
User-Agent: Mutt/1.5.9i
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: kleptog@svana.org
X-SA-Exim-Scanned: No (on svana.org); SAEximRunCond expanded to false
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200612/400
X-Sequence-Number: 22456


--5gxpn/Q6ypwruk0T
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 15, 2006 at 10:28:08AM +0000, Simon Riggs wrote:
> Until we work out a better solution we can fix this in two ways:
>=20
> 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ...
>=20
> 2. enable_analyze_timer =3D off | on (default) (USERSET)

What exactly would this do? Only count actual rows or something? I
wrote a patch that tried statistical sampling, but the figures were too
far off for people's liking.

> A performance drop of 4x-10x is simply unacceptable when trying to tune
> queries where the current untuned time is already too high. Tying down
> production servers for hours on end when we know for certain all they
> are doing is calling gettimeofday millions of times is not good. This
> quickly leads to the view from objective people that PostgreSQL doesn't
> have a great optimizer, whatever we say in its defence. I don't want to
> leave this alone, but I don't want to spend a month fixing it either.

I think the best option is setitimer(), but it's not POSIX so
platform support is going to be patchy.

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.

Have a nice day,
--=20
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to l=
itigate.

--5gxpn/Q6ypwruk0T
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFFgn3gIB7bNG8LQkwRAt5MAJ9nP2i0ID3j+ZJPuYsJYJWdC89o4QCePHb0
1eftAbtcNOuJsNML7/C+p1w=
=YEID
-----END PGP SIGNATURE-----

--5gxpn/Q6ypwruk0T--