Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 0CBB41337BD0 for ; Tue, 8 Feb 2011 16:09:58 -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 69605-09 for ; Tue, 8 Feb 2011 20:09:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mail.postgresql.org (Postfix) with ESMTP id 0FFB4133616B for ; Tue, 8 Feb 2011 16:09:46 -0400 (AST) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MPc3R-1PiF3H0401-004eoD; Tue, 08 Feb 2011 21:09:43 +0100 Message-ID: <4D51A304.4070003@2ndquadrant.com> Date: Tue, 08 Feb 2011 15:09:40 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Marti Raudsepp CC: Kevin Grittner , sthomas@peak6.com, Maciek Sakrejda , felix , "pgsql-performance@postgresql.org" Subject: Re: Really really slow select count(*) References: <4D4C138C.7010304@2ndquadrant.com> <4D4C1555.40209@peak6.com> <4D4C2AC3.5020804@peak6.com> <4D5151C6.7040109@peak6.com> <4D511C99020000250003A62D@gw.wicourts.gov> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:94TXr+wOG5m7VXy52At7+xBdemWWq2qIsq4twfPLjTU YWaoET2W17/emoWRq9dK8mEScdEoR/g6eqJX8TDMGEi+6HASzw suW8w7SUh4CqTIY+Nk1Li+HRo6mXFI+1C+J3eZoLeQVd4aHwxp 4BlWPnyD6qdEHMEIqnQIv8pW2tQnPgnMmbpuRyfARWoyQo/341 q7wS8wYT53oeZXM350e+ORMyq5FyqL5Z6DDf7HKOds= 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: 201102/313 X-Sequence-Number: 42451 Marti Raudsepp wrote: > I couldn't find any past discussions about changing the default to "fast". > Are there any reasons why that cannot be done in a future release? > Well, it won't actually help as much as you might think. It's possible for clients to be in a state where fast shutdown doesn't work, either. You either have to kill them manually or use an immediate shutdown. Kevin and I both suggested a "fast plus timeout then immediate" behavior is what many users seem to want. My comments were at http://archives.postgresql.org/pgsql-hackers/2009-09/msg01145.php ; for an example of how fast shutdown can fail see http://archives.postgresql.org/pgsql-bugs/2009-03/msg00062.php -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books