Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 0E72B2E0255 for ; Fri, 7 Mar 2008 01:38:42 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 39698-04 for ; Fri, 7 Mar 2008 01:38:38 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by postgresql.org (Postfix) with ESMTP id 76E162E2D8F for ; Fri, 7 Mar 2008 01:38:39 -0400 (AST) Received: by wa-out-1112.google.com with SMTP id m38so393695waf.5 for ; Thu, 06 Mar 2008 21:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=nmBBTvYz1sQE0RN/th/B5waq5h+FCSUvyRuLu7IV2eo=; b=soMGIPW0Go+TncT/BOdBpFw7oCxOrTdPR/wnemH1XC2RdfxqZdxCuBsxjRw212WI4VPqRkbWfSCqU3lc5FVmqKwqUroZfcml8RhDKMhq6ta96AijWtxhYZ/CvdWfNdZmPeSbVPUPjJBNqTZgvDilfP8nDUr4CtBIDSfX64fwQXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=tkkgrDRKci/Ob22cd2n7xtRDutUYV3bieeOiaBLkeulR4QE9GWWbytu8myTDm6GT73YA7Hd3YhPeO1ejAS++hb409RKRUNl8XxokaKWeFy5mNTBrMvAWKb4aJvzBmAcTm3w4mCZ5EjF0uV9RsTOotaqnWq3IzBBG8EMJY0nw6Ng= Received: by 10.114.193.1 with SMTP id q1mr1444479waf.75.1204868318299; Thu, 06 Mar 2008 21:38:38 -0800 (PST) Received: from ?192.168.1.102? ( [24.7.64.54]) by mx.google.com with ESMTPS id j6sm1616084wah.6.2008.03.06.21.38.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 06 Mar 2008 21:38:37 -0800 (PST) Message-ID: <47D0D4E8.6040808@gmail.com> Date: Thu, 06 Mar 2008 21:38:48 -0800 From: paul rivers User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Craig James CC: Tom Lane , pgsql-performance@postgresql.org Subject: Re: count * performance issue References: <20080306060829.GA21084@a-kretschmer.de> <47CF8EA6.8070503@mark.mielke.cc> <20080306063643.GB21084@a-kretschmer.de> <3E9C3A51-C28E-4B75-9739-E344DAC72880@fastcrypt.com> <47D00DB2.7040007@emolecules.com> <18451.1204824562@sss.pgh.pa.us> <47D0AFC1.5070305@emolecules.com> In-Reply-To: <47D0AFC1.5070305@emolecules.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/145 X-Sequence-Number: 29099 Craig James wrote: > Tom Lane wrote: >> Craig James writes: >>> Count() on Oracle and MySQL is almost instantaneous, even for very >>> large tables. So why can't Postgres do what they do? >> >> AFAIK the above claim is false for Oracle. They have the same >> transactional issues we do. > > My experience doesn't match this claim. When I ported my application > from Oracle to Postgres, this was the single biggest performance > problem. count() in Oracle was always very fast. We're not talking > about a 20% or 50% difference, we're talking about a small fraction of > a second (Oracle) versus a minute (Postgres) -- something like two or > three orders of magnitude. > > It may be that Oracle has a way to detect when there's no transaction > and use a faster method. If so, this was a clever optimization -- in > my experience, that represents the vast majority of the times you want > to use count(). It's not very useful to count the rows of a table > that many apps are actively modifying since the result may change the > moment your transaction completes. Most of the time when you use > count(), it's because you're the only one modifying the table, so the > count will be meaningful. > > Craig > > Oracle will use a btree index on a not null set of columns to do a fast full index scan, which can be an order of magnitude or faster compared to a table scan. Also, Oracle can use a bitmap index (in cases where a bitmap index isn't otherwise silly) for a bitmap fast index scan/bitmap conversion for similar dramatic results. For "large" tables, Oracle is not going to be as fast as MyISAM tables in MySQL, even with these optimizations, since MyISAM doesn't have to scan even index pages to get a count(*) answer against the full table. Paul