Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 10AB71336971 for ; Wed, 12 Jan 2011 13:43:38 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 70856-08 for ; Wed, 12 Jan 2011 17:43:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-iw0-f174.google.com (mail-iw0-f174.google.com [209.85.214.174]) by mail.postgresql.org (Postfix) with ESMTP id 9D66C133616B for ; Wed, 12 Jan 2011 13:43:30 -0400 (AST) Received: by iwn9 with SMTP id 9so746807iwn.19 for ; Wed, 12 Jan 2011 09:43:30 -0800 (PST) Received: by 10.42.175.70 with SMTP id az6mr1265840icb.428.1294852651022; Wed, 12 Jan 2011 09:17:31 -0800 (PST) Received: from tech304 (supranet-tech.secure-on.net [66.170.8.18]) by mx.google.com with ESMTPS id k38sm696104ick.9.2011.01.12.09.17.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 Jan 2011 09:17:30 -0800 (PST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: pgsql-admin@postgresql.org Subject: Re: Postgresql 9.0.2 explain analyze very slow (10x), compared to actual query time References: <201101111753.22602.achill@matrix.gatewaynet.com> <201101121318.44007.achill@matrix.gatewaynet.com> <25677.1294844873@sss.pgh.pa.us> <201101121817.11143.achill@matrix.gatewaynet.com> <27365.1294850720@sss.pgh.pa.us> Date: Wed, 12 Jan 2011 11:17:28 -0600 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Mark Felder" Message-ID: In-Reply-To: <27365.1294850720@sss.pgh.pa.us> User-Agent: Opera Mail/11.01 (FreeBSD) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.6 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7 X-Spam-Level: X-Archive-Number: 201101/61 X-Sequence-Number: 36501 On Wed, 12 Jan 2011 10:45:20 -0600, Tom Lane wrote: > > The short of it is that cheap motherboards tend to provide cheap clock > hardware that takes about a microsecond to read. I'm not sure how gettimeofday() works, but is there a slight chance this could be alleviated by choosing a different kern.timecounter.hardware option? kern.timecounter.choice: TSC(800) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast Or does the kernel timer stuff have nothing to do with gettimeofday()? Regards, Mark