Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 20FC59FA0B7; Fri, 15 Dec 2006 08:16:30 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 80518-04; Fri, 15 Dec 2006 08:16:22 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from localhost.localdomain (unknown [62.232.55.118]) by postgresql.org (Postfix) with ESMTP id 5E5A39FA274; Fri, 15 Dec 2006 08:16:22 -0400 (AST) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by localhost.localdomain with esmtp (Exim 4.62) (envelope-from ) id 1GvByq-0007tj-2J; Fri, 15 Dec 2006 12:16:00 +0000 From: Gregory Stark To: "Martijn van Oosterhout" Cc: "Simon Riggs" , "Tom Lane" , "Kelly Burkhart" , "Evgeny Gridasov" , , Subject: Re: [PERFORM] EXPLAIN ANALYZE on 8.2 In-Reply-To: <20061215105008.GD958@svana.org> (Martijn van Oosterhout's message of "Fri, 15 Dec 2006 11:50:08 +0100") Organization: EnterpriseDB 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> <29450.1166141131@sss.pgh.pa.us> <1166178488.3882.56.camel@silverbirch.site> <20061215105008.GD958@svana.org> X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX" 3162) Date: Fri, 15 Dec 2006 12:15:59 +0000 Message-ID: <87irgdiccg.fsf@enterprisedb.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/595 X-Sequence-Number: 95075 "Martijn van Oosterhout" writes: > BTW, doing gettimeofday() without kernel entry is not really possible. That's too strong a conclusion. Doing gettimeofday() without some help from the kernel isn't possible but it isn't necessary to enter the kernel for each call. There are various attempts at providing better timing infrastructure at low overhead but I'm not sure what's out there currently. I expect to do this what we'll have to do is invent a pg_* abstraction that has various implementations on different architectures. On Solaris it can use DTrace internally, on Linux it might have something else (or more likely several different options depending on the age and config options of the kernel). -- Gregory Stark EnterpriseDB http://www.enterprisedb.com