Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 940069F9B05; Fri, 15 Dec 2006 12:10:42 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 63638-03; Fri, 15 Dec 2006 12:10:30 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id EEC049FA463; Fri, 15 Dec 2006 12:10:29 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from stark.xeocode.com (modemcable238.55-70-69.static.videotron.ca [69.70.55.238]) by svr4.postgresql.org (Postfix) with ESMTP id 61E005AF90B; Fri, 15 Dec 2006 16:10:29 +0000 (GMT) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1GvFdT-0000AE-00; Fri, 15 Dec 2006 11:10:11 -0500 To: Tom Lane Cc: "Martijn van Oosterhout" , "Simon Riggs" , "Kelly Burkhart" , "Evgeny Gridasov" , pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: [HACKERS] EXPLAIN ANALYZE on 8.2 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> <87irgdiccg.fsf@enterprisedb.com> <9096.1166197556@sss.pgh.pa.us> In-Reply-To: <9096.1166197556@sss.pgh.pa.us> From: Gregory Stark Organization: EnterpriseDB Date: 15 Dec 2006 11:10:10 -0500 Message-ID: <87mz5pgmxp.fsf@stark.xeocode.com> Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/415 X-Sequence-Number: 22471 Tom Lane writes: > Gregory Stark writes: > > 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. > > You've got to be kidding. Surely it's glibc's responsibility, not ours, > to implement gettimeofday correctly for the hardware. Except for two things: a) We don't really need gettimeofday. That means we don't need something sensitive to adjustments made by ntp etc. In fact that would be actively bad. Currently if the user runs "date" to reset his clock back a few days I bet interesting things happen to a large explain analyze that's running. In fact we don't need something that represents any absolute time, only time elapsed since some other point we choose. That might be easier to implement than what glibc has to do to implement gettimeofday fully. b) glibc may not want to endure an overhead on every syscall and context switch to make gettimeofday faster on the assumption that gettimeofday is a rare call and it should pay the price rather than imposing an overhead on everything else. Postgres knows when it's running an explain analyze and a 1% overhead would be entirely tolerable, especially if it affected the process pretty much evenly unlike the per-gettimeofday-overhead which can get up as high as 100% on some types of subplans and is negligible on others. And more to the point Postgres wouldn't have to endure this overhead at all when it's not needed whereas glibc has no idea when you're going to need gettimeofday next. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com