Re: [HACKERS] Much Ado About COUNT(*)

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Wes <wespvp(at)syntegra(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Postgres general mailing list <pgsql-general(at)postgresql(dot)org>
Subject: Re: [HACKERS] Much Ado About COUNT(*)
Date: 2005-01-14 17:22:11
Message-ID: 87d5w8udrw.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Wes <wespvp(at)syntegra(dot)com> writes:

> On 1/13/05 6:44 PM, "Greg Stark" <gsstark(at)mit(dot)edu> wrote:
>
> > That's simply false. Oracle does indeed have to count the records one by one.

> Ok, I stand corrected - I was given some wrong information. However, my
> experience has been that count(*) on Oracle is a whole lot faster than
> PostgreSQL - what appeared instantaneous on Oracle took some time on
> PostgreSQL. That was one of the first things I noticed when moving a
> database application to PostgreSQL. I've since disposed of the Oracle
> database, so can't go back and retest.

If it was instantaneous then the data must have all been in cache. A lot of
Oracle kudos really come down to the fact that Oracle is often run on beefier
machines than others.

But if it was merely 2x as fast or so, more if the table was really wide, then
it could have just been because of the fast index-only scan.

If it was more than 2-4x as fast for a narrow table and you don't think the
whole thing was in cache then I would start to wonder about whether your
postgres table suffered from bloat from not having vacuum run frequently
enough or having the fsm settings too low.

--
greg

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Frank D. Engel, Jr. 2005-01-14 17:39:04 Re: [HACKERS] Much Ado About COUNT(*)
Previous Message Wes 2005-01-14 17:04:43 Re: [HACKERS] Much Ado About COUNT(*)

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2005-01-14 17:24:16 Re: FATAL: catalog is missing 1 attribute(s) for relid
Previous Message Tom Lane 2005-01-14 17:20:56 Re: FATAL: catalog is missing 1 attribute(s) for relid 16396