I hesitate to raise this issue again, but I've noticed something which I
thought might be worth mentioning. I've never thought the performance
of count(*) on a table was a significant issue, but I'm prepared to say
that -- for me, at least -- it is officially and totally a NON-issue.
We are replicating data from 72 source databases, each with the
official copy of a subset of the data, to four identical consolidated
databases, spread to separate locations, to serve our web site and other
organization-wide needs. Currently, two of these central databases are
running a commercial product and two are running PostgreSQL. There have
been several times that I have run a SELECT COUNT(*) on an entire table
on all central machines. On identical hardware, with identical data,
and equivalent query loads, the PostgreSQL databases have responded with
a count in 50% to 70% of the time of the commercial product, in spite of
the fact that the commercial product does a scan of a non-clustered
index while PostgreSQL scans the data pages.
The tables have had from a few million to 132 million rows. The
databases are about 415 GB each. The servers have 6 GB RAM each. We've
been running PostgreSQL 8.1, tuned and maintained based on advice from
the documentation and these lists.
I suspect that where people report significantly worse performance for
count(*) under PostgreSQL than some other product, it may sometimes be
the case that they have not properly tuned PostgreSQL, or paid attention
to maintenance issues regarding dead space in the tables.
My recent experience, for what it's worth.
-Kevin
