Af far as I know Oracle doesn't have any short cut (along the lines of
what is being discussed in this thread) for this operation. However
Oracle is more efficient in providing the answer than postgres currently
is. While postgres needs to perform a full scan on the table, Oracle
will only need to perform a full index scan on the primary key if one
exists. Since the index will likely have much less data than the full
table this will result in fewer IOs and be faster than what postgres
does, but it still takes a while for large tables even in Oracle.
thanks,
--Barry
Mike Mascari wrote:
> Dann Corbit wrote:
>
>>I guess that this model can be viewed as "everything is a snapshot".
>>It seems plain that the repercussions for a data warehouse and for
>>reporting have not been thought out very well. This is definitely
>>very, very bad in that arena. I suppose that reporting could still
>>be accomplished, but it would require pumping the data into a new
>>copy of the database that does not allow writes at all. Yuck.
>>
>>At any rate, there is clearly a concept of cardinality in any case.
>>Perhaps the information would have to be kept as part of the
>>connection. If (after all) you cannot even compute cardinality
>>for a single connection then the database truly is useless. In
>>fact, under a scenario where cardinality has no meaning, neither does
>>select count() since that is what it measures. Might as well
>>remove it from the language.
>>
>>I have read a couple books on Postgresql and somehow missed the
>>whole MVCC idea. Maybe after I understand it better the clammy
>>beads of sweat on my forehead will dry up a little.
>
>
> Oracle is also a MVCC database. So this notion that MVCC somehow makes
> it inappropriate for data warehousing would imply that Oracle is also
> inappropriate. However, in your defense, Oracle did apparently find
> enough customer demand for a MVCC-compatible hack of COUNT() to
> implement a short-cut route to calculate its value...
>
> Mike Mascari
> mascarm@mascari.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
