X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id B617D52A00 for ; Thu, 7 Jul 2005 19:48:10 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 00505-09 for ; Thu, 7 Jul 2005 22:48:06 +0000 (GMT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by svr1.postgresql.org (Postfix) with ESMTP id B6D9F52A20 for ; Thu, 7 Jul 2005 19:48:02 -0300 (ADT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j67Mm5gD022277 for ; Thu, 7 Jul 2005 15:48:05 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 7 Jul 2005 15:48:04 -0700 Received: from [17.203.12.99] (amw.apple.com [17.203.12.99]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id j67Mm38t000858 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 7 Jul 2005 15:48:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v730) Content-Transfer-Encoding: 7bit Message-Id: <9EF2931D-1097-470D-8ECB-59D00166C96F@apple.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: pgsql-sql@postgresql.org From: Varun Mehta Subject: Make COUNT(*) Faster? Date: Thu, 7 Jul 2005 15:48:39 -0700 X-Mailer: Apple Mail (2.730) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200507/51 X-Sequence-Number: 22029 Hello all you PostgreSQL/SQL gurus! I've started using PostgreSQL pretty recently, and I am quite disturbed about the performance of a simple SELECT COUNT(*) FROM table. What should (in my mind) be a nearly instantaneous operation instead takes nearly 700ms in a table with only 87k rows of data! If I run an EXPLAIN on this query I can see that it is doing a sequential scan, which seems quite needless, as surely this information is cached in some secret location. It is very possible that I am missing something, so I ask you: is there a faster way to find out how many rows are in a table? I've tried doing a COUNT(column) where I have an index on column, but it still does a sequential scan and it is still very very slow. What are my options? I offer you many thanks in advance, Varun Mehta