Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id A7A7D1337B68 for ; Thu, 3 Feb 2011 20:50:01 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 05535-03 for ; Fri, 4 Feb 2011 00:49:54 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from wizmail.org (wizmail.org [217.146.107.12]) by mail.postgresql.org (Postfix) with ESMTP id 5A7401337B49 for ; Thu, 3 Feb 2011 20:49:54 -0400 (AST) Received: from ebony.jgh.adsl.wizards.co.uk ([217.146.123.59]) from_AS 16353by wizmail.org with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.72) id 1Pl9s1-0001Jt-Vi (return-path ); Fri, 04 Feb 2011 00:49:54 +0000 Message-ID: <4D4B4D30.2060007@wizmail.org> Date: Fri, 04 Feb 2011 00:49:52 +0000 From: Jeremy Harris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090320 Fedora/2.0.0.21-1.fc9 Thunderbird/2.0.0.21 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: [HACKERS] Slow count(*) again... References: <201102012247.p11Ml6u02682@momjian.us> <4D48914B.4050403@dunslane.net> <4D489AD1.1010105@vmsinfo.com> <4D499E55.4020107@vmsinfo.com> <4D49A6B9.4060608@2ndquadrant.com> <4D49C482.4010707@vmsinfo.com> <4D49F0BA.9000901@2ndquadrant.com> <4D4A16BF.1020304@vmsinfo.com> <4D4A4844.3020409@2ndquadrant.com> <4D4AD9F6.6040903@vmsinfo.com> <4D4AE16E.9040807@peak6.com> <4D4B17B4.9030406@vmsinfo.com> <4D4B235C.1080308@catalyst.net.nz> In-Reply-To: <4D4B235C.1080308@catalyst.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201102/143 X-Sequence-Number: 42281 On 2011-02-03 21:51, Mark Kirkwood wrote: > The cases I've seen in production typically involve "outgrowing" optimizer parameter settings: (e.g work_mem, effective_cache_size) as the application dataset gets bigger over time. An argument in favour of the DBMS maintaining a running estimate of such things. -- Jeremy