Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 14F002E020C for ; Fri, 7 Mar 2008 21:42:06 -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 87707-06 for ; Fri, 7 Mar 2008 21:41:55 -0400 (AST) Received: from mx1.hub.org (mx1.hub.org [200.46.204.176]) by postgresql.org (Postfix) with ESMTP id 7EC002E0206 for ; Fri, 7 Mar 2008 21:42:01 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mx1.hub.org (Postfix) with ESMTP id 5FCAA16D94C0 for ; Fri, 7 Mar 2008 21:39:37 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m281cFMX013346; Fri, 7 Mar 2008 20:38:15 -0500 (EST) To: josh@agliodbs.com cc: pgsql-performance@postgresql.org, Craig James Subject: Re: count * performance issue In-reply-to: <200803071727.36146.josh@agliodbs.com> References: <47D00DB2.7040007@emolecules.com> <18451.1204824562@sss.pgh.pa.us> <200803071727.36146.josh@agliodbs.com> Comments: In-reply-to Josh Berkus message dated "Fri, 07 Mar 2008 17:27:35 -0800" Date: Fri, 07 Mar 2008 20:38:15 -0500 Message-ID: <13345.1204940295@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/172 X-Sequence-Number: 29126 Josh Berkus writes: > Tom, >>> 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. > Nope. Oracle's MVCC is implemented through rollback segments, rather than > non-overwriting the way ours is. So Oracle can just do a count(*) on the > index, then check the rollback segment for any concurrent > update/delete/insert activity and adjust the count. This sucks if there's > a *lot* of concurrent activity, but in the usual case it's pretty fast. Well, scanning an index to get a count might be significantly faster than scanning the main table, but it's hardly "instantaneous". It's still going to take time proportional to the table size. Unless they keep a central counter of the number of index entries; which would have all the same serialization penalties we've talked about before... regards, tom lane