From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | josh(at)agliodbs(dot)com |
Cc: | pgsql-performance(at)postgresql(dot)org, Craig James <craig_james(at)emolecules(dot)com> |
Subject: | Re: count * performance issue |
Date: | 2008-03-08 01:38:15 |
Message-ID: | 13345.1204940295@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | petchimuthu lingam | 2008-03-08 04:07:01 | join query performance |
Previous Message | Josh Berkus | 2008-03-08 01:27:35 | Re: count * performance issue |