Re: count * performance issue - Mailing list pgsql-performance

From Tom Lane
Subject Re: count * performance issue
Date
Msg-id 13345.1204940295@sss.pgh.pa.us
Whole thread Raw
In response to Re: count * performance issue  (Josh Berkus <josh@agliodbs.com>)
Responses Re: count * performance issue  (Greg Smith <gsmith@gregsmith.com>)
Re: count * performance issue  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-performance
Josh Berkus <josh@agliodbs.com> writes:
> Tom,
>>> Count() on Oracle and MySQL is almost instantaneous, even for very
>>> large tables. So why can't Postgres do what they do?
>>
>> AFAIK the above claim is false for Oracle.  They have the same
>> transactional issues we do.

> Nope.  Oracle's MVCC is implemented through rollback segments, rather than
> non-overwriting the way ours is.  So Oracle can just do a count(*) on the
> index, then check the rollback segment for any concurrent
> update/delete/insert activity and adjust the count.  This sucks if there's
> a *lot* of concurrent activity, but in the usual case it's pretty fast.

Well, scanning an index to get a count might be significantly faster
than scanning the main table, but it's hardly "instantaneous".  It's
still going to take time proportional to the table size.

Unless they keep a central counter of the number of index entries;
which would have all the same serialization penalties we've talked
about before...

            regards, tom lane

pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: count * performance issue
Next
From: "petchimuthu lingam"
Date:
Subject: join query performance