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
duringa 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@postgresql.org on behalf of Jeffrey Melloy
Sent: Thu 10/6/2005 3:47 PM
To: Neil Conway
Cc: Aly S.P Dharshi; pgsql-general@postgresql.org
Subject: Re: [GENERAL] 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!