Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 16D609FBB16 for ; Thu, 22 Mar 2007 11:52:37 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-new, port 10024) with ESMTP id 13162-04 for ; Thu, 22 Mar 2007 11:52:29 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail.envysolutions.com (unknown [206.248.142.186]) by postgresql.org (Postfix) with ESMTP id 19DE29FB7E1 for ; Thu, 22 Mar 2007 11:52:29 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.envysolutions.com (Postfix) with ESMTP id 4F12E54042 for ; Thu, 22 Mar 2007 10:52:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.envysolutions.com Received: from mail.envysolutions.com ([127.0.0.1]) by localhost (mark.mielke.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJg+haDFJyy8 for ; Thu, 22 Mar 2007 10:52:27 -0400 (EDT) Received: by mail.envysolutions.com (Postfix, from userid 500) id 2EA4C5404C; Thu, 22 Mar 2007 10:52:27 -0400 (EDT) Date: Thu, 22 Mar 2007 10:52:27 -0400 From: mark@mark.mielke.cc To: pgsql-performance@postgresql.org Subject: Re: Performance of count(*) Message-ID: <20070322145226.GA15670@mark.mielke.cc> References: <200703221208.19358.albert@sedifa.com> <20070322141807.GE11402@mathom.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070322141807.GE11402@mathom.us> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200703/326 X-Sequence-Number: 23731 On Thu, Mar 22, 2007 at 10:18:10AM -0400, Michael Stone wrote: > IIRC, that's basically what you get with the mysql count anyway, since > there are corner cases for results in a transaction. Avoiding those > cases is why the postgres count takes so long; sometimes that's what's > desired and sometimes it is not. Adding to this point: In any production system, the count presented to the user is usually wrong very shortly after it is displayed anyways. Transactions in the background or from other users are adding or removing items, perhaps even before the count reaches the user's display. The idea of transaction-safety for counts doesn't apply in this case. Both the transaction and the number are complete before the value is displayed. In my own systems, I rarely use count(*) for anything except user visible results. For the PostgreSQL system I use, I keep a table of counts, and lock the row for update when adding or removing items. This turns out to be best in this system anyways, as I need my new rows to be ordered, and locking the 'count' row lets me assign a new sequence number for the row. (Don't want to use SEQUENCE objects, as there could as the rows are [key, sequence, data], with thousands or more keys) Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/