Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id B600D1337BC5 for ; Wed, 13 Oct 2010 05:44:26 -0300 (ADT) 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 52392-06 for ; Wed, 13 Oct 2010 08:44:19 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.125]) by mail.postgresql.org (Postfix) with ESMTP id 5493A1337B54 for ; Wed, 13 Oct 2010 05:44:19 -0300 (ADT) X-Authority-Analysis: v=1.1 cv=vbQZhf6WRU4XF+4tPWNJEMYU0N1CowIjcRZ/qR/IBDs= c=1 sm=0 a=_6Iw8BWMfOIA:10 a=8nJEP1OIZ-IA:10 a=RAii6je2cdnAH6ATCOpc6g==:17 a=_Ixf_7qHAAAA:8 a=G18DIA4OVUBQVh2l2IEA:9 a=VohbXR87RfKtRTR8Ps2gM4LLb2wA:4 a=wPNLvfGTeEIA:10 a=ryAo9hy1-OkA:10 a=6vsjEBoLwlAA:10 a=0tfO7MgyNwYA:10 a=RAii6je2cdnAH6ATCOpc6g==:117 X-Cloudmark-Score: 0 X-Originating-IP: 74.73.87.196 Received: from [74.73.87.196] ([74.73.87.196:54771] helo=[192.168.1.103]) by hrndva-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 36/D5-23284-95175BC4; Wed, 13 Oct 2010 08:44:09 +0000 Message-ID: <4CB57159.2090501@vmsinfo.com> Date: Wed, 13 Oct 2010 04:44:09 -0400 From: Mladen Gogala User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Slow count(*) again... References: <201010091626.18636.neil.whelchel@gmail.com> <4CB2410C.6010603@postnewspapers.com.au> <201010102115.58729.neil.whelchel@gmail.com> <201010122347.20542.neil.whelchel@gmail.com> <4CB55D7E.8080902@catalyst.net.nz> In-Reply-To: <4CB55D7E.8080902@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.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201010/200 X-Sequence-Number: 40619 On 10/13/2010 3:19 AM, Mark Kirkwood wrote: > I think that major effect you are seeing here is that the UPDATE has > made the table twice as big on disk (even after VACUUM etc), and it has > gone from fitting in ram to not fitting in ram - so cannot be > effectively cached anymore. > In the real world, tables are larger than the available memory. I have tables of several hundred gigabytes in size. Tables shouldn't be "effectively cached", the next step would be to measure "buffer cache hit ratio", tables should be effectively used. -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 www.vmsinfo.com