From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Good News re count(*) in 8.1 |
Date: | 2006-02-22 17:42:02 |
Message-ID: | 13377.1140630122@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> 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.
Interesting. I think though that the people who are complaining come
from databases where COUNT(*) takes constant time because the DB keeps
a running count in the table's metadata.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Steinar H. Gunderson | 2006-02-22 17:52:44 | Re: Joins and full index scans...mysql vs postgres? |
Previous Message | ryan groth | 2006-02-22 17:26:47 | Joins and full index scans...mysql vs postgres? |