On Informix however it is blindingly fast, and can also be instantly conjured with the dbaccess tool (Info/Table/Status). They might be stashing this count somewhere, but it is not available when the table is locked, as during a load. However they do it, performance does not seem to suffer, and having this rapidly available is certainly nice. Especially when people are used to it.
Greg Williamson
DBA
GlobeXplorer LLC
-----Original Message-----
From: pgsql-general-owner@xxxxxxxxxxxxxx on behalf of Jeffrey Melloy
Sent: Thu 10/6/2005 3:47 PM
To: Neil Conway
Cc: Aly S.P Dharshi; pgsql-general@xxxxxxxxxxxxxx
Subject: Re: PostgreSQL Gotchas
Neil Conway wrote:
>
>"COUNT(*) very slow": this is a known issue -- see the -hackers archives
>for many prior discussions. MVCC makes this hard to solve effectively
>(whether applications should actually be using COUNT(*) on large tables
>with no WHERE clause is another matter...)
>
>-Neil
>
>
And it's not like a count(*) on an Oracle database of any decently-sized
dataset is blazing fast, or even in blazing's ballpark.
The only thing I could see actually being an issue is the random() one
and add missing from. The rest are trivial. The random() thing is
interesting, esoteric, and probably has never been a problem in a real
situation. (Or has exactly once, when he wrote that gotcha)
Jeff
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
!DSPAM:4345aeea115747915089936!
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
