Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id BD6BE9FA394; Fri, 15 Dec 2006 08:21:39 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 11530-02; Fri, 15 Dec 2006 08:21:34 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail01.enterprisedb.com (mail01.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id 9DDD29FA334; Fri, 15 Dec 2006 08:21:34 -0400 (AST) thread-index: AccgQ5Ga5kwr8EQTSvaZcvC+r/AYkA== Received: from [192.168.0.24] ([62.232.55.118]) by mail01.enterprisedb.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Dec 2006 07:21:33 -0500 Subject: Re: [HACKERS] EXPLAIN ANALYZE on 8.2 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-Class: urn:content-classes:message Importance: normal From: "Simon Riggs" To: "Martijn van Oosterhout" Cc: "Tom Lane" , "Kelly Burkhart" , "Evgeny Gridasov" , , In-Reply-To: <20061215105008.GD958@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> <29450.1166141131@sss.pgh.pa.us> <1166178488.3882.56.camel@silverbirch.site> <20061215105008.GD958@svana.org> Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Dec 2006 12:20:46 +0000 Message-ID: <1166185247.3882.69.camel@silverbirch.site> MIME-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Dec 2006 12:21:33.0984 (UTC) FILETIME=[8F256A00:01C72043] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/403 X-Sequence-Number: 22459 On Fri, 2006-12-15 at 11:50 +0100, Martijn van Oosterhout wrote: > 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: > > > > 1. EXPLAIN ANALYZE [ [ WITH | WITHOUT ] TIME STATISTICS ] ... > > > > 2. enable_analyze_timer = off | on (default) (USERSET) > > What exactly would this do? Only count actual rows or something? Yes. It's better to have this than nothing at all. > I > wrote a patch that tried statistical sampling, but the figures were too > far off for people's liking. Well, I like your ideas, so if you have any more... Maybe sampling every 10 rows will bring things down to an acceptable level (after the first N). You tried less than 10 didn't you? Maybe we can count how many real I/Os were required to perform each particular row, so we can adjust the time per row based upon I/Os. ISTM that sampling at too low a rate means we can't spot the effects of cache and I/O which can often be low frequency but high impact. > I think the best option is setitimer(), but it's not POSIX so > platform support is going to be patchy. Don't understand that. I thought that was to do with alarms and signals. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com