Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 3D3C91337B93 for ; Tue, 26 Apr 2011 15:54:46 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 55969-05 for ; Tue, 26 Apr 2011 18:54:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.gransy.com (mail.gransy.com [82.208.29.194]) by mail.postgresql.org (Postfix) with ESMTP id A92901337BBB for ; Tue, 26 Apr 2011 15:54:35 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by mail.gransy.com (Postfix) with ESMTP id 059464A2285 for ; Tue, 26 Apr 2011 20:54:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at nathalia.gransy.com Received: from mail.gransy.com ([127.0.0.1]) by localhost (Nathalka.gransy.com.gransy.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rkx3d0Bbuyj for ; Tue, 26 Apr 2011 20:54:34 +0200 (CEST) Received: from [192.168.1.221] (ip-94-112-0-189.net.upcbroadband.cz [94.112.0.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.gransy.com (Postfix) with ESMTPSA id 54CF44A21EC for ; Tue, 26 Apr 2011 20:54:34 +0200 (CEST) Message-ID: <4DB714EA.6090106@fuzzy.cz> Date: Tue, 26 Apr 2011 20:54:34 +0200 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101219 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Performance References: <20110412171855.GA14292@tux> <4DA496FA.3070908@fuzzy.cz> <8F22D592-23C1-4A3C-94A5-48363332ADD3@darkstatic.com> <4DA4BFA2.5060601@fuzzy.cz> <4DA4D40A.4010200@fuzzy.cz> <4DA56DA8020000250003C783@gw.wicourts.gov> <4DA6216E.9020907@fuzzy.cz> <11589CE9-B860-4024-BCDF-88FBE00FB9BC@gmail.com> In-Reply-To: <11589CE9-B860-4024-BCDF-88FBE00FB9BC@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201104/362 X-Sequence-Number: 43424 Dne 26.4.2011 07:35, Robert Haas napsal(a): > On Apr 13, 2011, at 6:19 PM, Tomas Vondra wrote: >> Yes, I've had some lectures on non-linear programming so I'm aware that >> this won't work if the cost function has multiple extremes (walleys / >> hills etc.) but I somehow suppose that's not the case of cost estimates. > > I think that supposition might turn out to be incorrect, though. Probably > what will happen on simple queries is that a small change will make no > difference, and a large enough change will cause a plan change. On > complex queries it will approach continuous variation but why > shouldn't there be local minima? Aaaah, damn! I was not talking about cost estimates - those obviously do not have this feature, as you've pointed out (thanks!). I was talking about the 'response time' I mentioned when describing the autotuning using real workload. The idea is to change the costs a bit and then measure the average response time - if the overall performance improved, do another step in the same direction. Etc. I wonder if there are cases where an increase of random_page_cost would hurt performance, and another increase would improve it ... And I'm not talking about individual queries, I'm talking about overall performance. regards Tomas