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
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(*) |
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 |