Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 9FE139FB444 for ; Thu, 3 May 2007 21:22:58 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 95098-07 for ; Thu, 3 May 2007 21:22:50 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mail.net-domino.com (www.net-domino.com [74.208.11.96]) by postgresql.org (Postfix) with ESMTP id 8B12C9FB430 for ; Thu, 3 May 2007 21:22:55 -0300 (ADT) Received: from [127.0.0.1] (u15245314.onlinehome-server.com [74.208.11.96]) by mail.net-domino.com (8.13.7/8.13.6) with ESMTP id l440MlX2018276 for ; Thu, 3 May 2007 20:22:51 -0400 Message-ID: <463A7D12.2010302@mochima.com> Date: Thu, 03 May 2007 20:23:46 -0400 From: Carlos Moreno User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning References: <200705010923.47951.josh@agliodbs.com> <200705031221.56226.josh@agliodbs.com> <463A4ED6.2040907@mochima.com> <463A6544.4090605@mochima.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Added-Header: Sample_milter accepted message X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/34 X-Sequence-Number: 24424 > I don't think it's that hard to get system time to a reasonable level > (if this config tuner needs to run for a min or two to generate > numbers that's acceptable, it's only run once) > > but I don't think that the results are really that critical. Still --- this does not provide a valid argument against my claim. Ok, we don't need precision --- but do we *need* to have less precision?? I mean, you seem to be proposing that we deliberately go out of our way to discard a solution with higher precision and choose the one with lower precision --- just because we do not have a critical requirement for the extra precision. That would be a valid argument if the extra precision came at a considerable cost (well, or at whatever cost, considerable or not). But my point is still that obtaining the time in the right ballpark and obtaining the time with good precision are two things that have, from any conceivable point of view (programming effort, resources consumption when executing it, etc. etc.), the exact same cost --- why not pick the one that gives us the better results? Mostly when you consider that: > I'd argue that we don't even care about 1,000,000 times per second vs > 1,100,000 times per second, what we care about is 1,000,000 times per > second vs 100,000 times per second Part of my claim is that measuring real-time you could get an error like this or even a hundred times this!! Most of the time you wouldn't, and definitely if the user is careful it would not happen --- but it *could* happen!!! (and when I say could, I really mean: trust me, I have actually seen it happen) Why not just use an *extremely simple* solution that is getting information from the kernel reporting the actual CPU time that has been used??? Of course, this goes under the premise that in all platforms there is such a simple solution like there is on Linux (the exact name of the API function still eludes me, but I have used it in the past, and I recall that it was just three or five lines of code). Carlos --